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).
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 |