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

From: Lukas Fittl <lukas(at)fittl(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: 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-19 00:45:49
Message-ID: CAP53PkyEPa=aFZrd0crLgRJm1KGS0ykJ+1i2CwDfDNFKpCc+XQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 18, 2026 at 4:36 PM Lukas Fittl <lukas(at)fittl(dot)com> wrote:
> On Wed, Mar 18, 2026 at 1:49 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-03-19 00:52:22 Re: Proposal to allow setting cursor options on Portals
Previous Message Tom Lane 2026-03-19 00:40:55 Re: Feature freeze timezone change request