Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations

On Tue, Aug 12, 2025 at 04:54:10PM +0200, Benoit Tigeot wrote:
> I deliberately focused `calls_aborted` on executor-level failures
> rather than earlier phases (parser/analyzer/rewriter/planner) because
> they serve different operational purposes. Earlier phase failures are
> typically development-time errors (syntax mistakes, missing tables,
> type mismatches) that don't provide actionable operational insights.
> Executor aborts represent runtime operational issues (query timeouts,
> cancellations, resource exhaustion, lock conflicts, etc.) that
> indicate performance degradation or capacity problems requiring
> attention. This design keeps the feature focused on what matters for
> production monitoring: distinguishing between queries that "worked
> before but now fail operationally" versus "never worked due to code
> bugs." The implementation is also cleaner, avoiding the complexity of
> hooking multiple subsystems and classifying different error types but
> of course I may be wrong. ;)

That seems kind of limited to me in scope. The executor is only one
part of the system. I would have considered using an xact callback
when a transaction is aborted if I were to do a patch like the one you
are proposing, to know how many times a transaction is failing at a
specific phase, because you should know the latest query_id in this
case to be able to put a counter update in the correct slot (right?).

+-- aborted calls tracking
+SELECT pg_sleep(0.5);
+ pg_sleep
+----------
+
+(1 row)

Using hardcoded sleep times for deterministic tests is never a good
idea. On fast machines, they eat time for nothing. And if not
written correctly, they may not achieve their goal on slow machines
because the sleep threshold may be reached before the custom action is
taken. If you want to force a failure, you should just use a SQL that
you know would fail at execution time (based on your implementation
expects).
--
Michael