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

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Benoit Tigeot <benoit(dot)tigeot(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations
Date: 2025-08-14 09:13:35
Message-ID: aJ2ov4KYM2vX4uAs@jrouhaud
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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(at)paquier(dot)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).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-08-14 09:29:08 Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture
Previous Message Amit Kapila 2025-08-14 09:09:53 Re: Excessive LOG messages from replication slot sync worker