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

On Wed, Mar 18, 2026 at 4:36 PM Lukas Fittl <lukas@fittl.com> wrote:
> On Wed, Mar 18, 2026 at 1:49 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> > There seems to be one more bug in this:
> >
> > 1. EXPLAIN ANALYZE fires a trigger
> > 2. The trigger function throws ERROR, InstrStopTrigger never runs
> > 3. ResOwnerReleaseInstrumentation runs but only checks
> > unfinalized_children, not triggers
> > 4. InstrStopFinalize discards the trigger entry
> > 5. Trigger instrumentation information shows 0
>
> Hmm, so I think you're correct that a trigger function error would
> cause any stack-based instrumentation from the trigger to get lost.
>
> In practice that doesn't matter today, since triggers never capture
> WAL/buffer usage data (only timing),

After twisting and turning this in my head more, I realize that's
actually not correct - as it stands, trigger instrumentation is
inheriting the instrumentation options from the overall query, and so
that will cause a typical EXPLAIN (ANALYZE) to also capture Buffer/WAL
usage for triggers - it just won't be shown in EXPLAIN.

Since its not used in practice, we could fix that by explicitly
setting INSTRUMENT_TIMER for triggers, but AFAIR Andres had noted on a
prior iteration that special casing this doesn't seem right, since we
should probably output buffer/WAL usage for triggers anyway.

So I guess that brings us back to, we should fix it with one of the
ways I mentioned. FWIW, I was able to create a test case in the
pg_session_buffer_usage module to that effect, so there is indeed a
current issue where activity during triggers gets lost and won't be
added to the overall totals on abort.

Thanks,
Lukas

-- 
Lukas Fittl