On 19/03/2026 02:45, Lukas Fittl wrote:
On Wed, Mar 18, 2026 at 4:36 PM Lukas Fittl <[email protected]> wrote:
On Wed, Mar 18, 2026 at 1:49 PM Zsolt Parragi <[email protected]> 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
