Re: Stack-based tracking of per-node WAL/buffer usage
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Lukas Fittl <lukas@fittl.com>, Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Tomas Vondra <tomas@vondra.me>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Andres Freund <andres@anarazel.de>, Peter Smith <smithpb2250@gmail.com>
Date: 2026-03-23T14:41:18Z
Lists: pgsql-hackers
On 19/03/2026 02:45, Lukas Fittl wrote: > 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. 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. - Heikki
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
instrumentation: Allocate query level instrumentation in ExecutorStart
- 2c16deee2f7d 19 (unreleased) landed
-
instrumentation: Move ExecProcNodeInstr to allow inlining
- 544000288ec8 19 (unreleased) landed
-
instrumentation: Separate per-node logic from other uses
- 5a79e78501f4 19 (unreleased) landed
-
instrumentation: Separate trigger logic from other uses
- 7d9b74df53e9 19 (unreleased) landed
-
instrumentation: Rename INSTR_TIME_LT macro to INSTR_TIME_GT
- 3218825271bd 19 (unreleased) landed
-
instrumentation: Keep time fields as instrtime, convert in callers
- e5a5e0a90750 19 (unreleased) landed