Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations
Date
Msg-id aJ2ov4KYM2vX4uAs@jrouhaud
Whole thread Raw
In response to Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations  (Benoit Tigeot <benoit.tigeot@gmail.com>)
List pgsql-hackers
On Thu, Aug 14, 2025 at 11:04:27AM +0200, Benoit Tigeot wrote:
> Thanks Michael
>
> Thu, Aug 14, 2025 at 10:18 AM, Michael Paquier <michael@paquier.xyz> wrote:
> >
> > 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?).
>
> I will make a v5 patch with this approach.

I'm wondering how useful that counter alone will be.  Since
pg_stat_statements is already quite large, wouldn't it be better to have
another extension that tracks something like (queryid, sqlstate), with maybe
the number of errors, the oldest and the newest timestamp or something like
that?  You would have way more information to diagnose various problems, and
can optionally use pg_stat_statements if you need the query text from there (vs
eg. the logs).



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Excessive LOG messages from replication slot sync worker
Next
From: Álvaro Herrera
Date:
Subject: Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture