Choosing Between statement_timeout and pg_cancel_backend for Safe Query Cancellation in Distributed YugabyteDB Transactions

Goal: ensure that cancelling a long‑running YSQL statement also aborts any associated distributed transaction promptly across all tablet leaders, preventing stale locks that could block concurrent workloads.

Constraints: statement_timeout is automatic and scoped to a single statement but counts network latency toward the timeout, which can cause false‑positive cancellations in geo‑distributed clusters; pg_cancel_backend provides manual, session‑wide control but requires superuser privileges and its abort‑propagation behavior changed between YugabyteDB releases (pre‑2.12 vs 2.12+), leaving uncertainty about how quickly tablet locks are released.

Which approach provides the most reliable abort propagation for distributed transactions in YugabyteDB 2.12+? How does statement_timeout interact with network‑induced latency in multi‑region deployments regarding false‑positive cancellations? Is there a configuration or session setting that can make pg_cancel_backend behave like statement_timeout regarding automatic cleanup without requiring superuser rights?