Re: Stack-based tracking of per-node WAL/buffer usage

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Lukas Fittl <lukas(at)fittl(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Smith <smithpb2250(at)gmail(dot)com>
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
Date: 2026-03-23 19:07:02
Message-ID: CAN4CZFOUTHdXuEAwrST8ueDxGJRe69zVgeVAY0osTjVkRZi_Lw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I'm looking at this finalize at resowner part of this patch, and this
> maybe a stupid question, but:
>
> Why does the instrumentation need to be "finalized" on abort? If you run
> EXPLAIN ANALYZE and the query aborts, you don't get to see the stats anyway.

The pg_session_buffer_usage in 0009 makes the information available, I
was able to see the issue with failing triggers with that. Even if
that part doesn't get committed in the end, a 3rd party extension
could still implement the same thing, and notice the missing
statistics. (And maybe it is useful to see some statistics about
failing queries?)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-03-23 19:08:52 [Patch] New pg_stat_tablespace view
Previous Message Sami Imseih 2026-03-23 19:01:22 Re: another autovacuum scheduling thread