Re: Stack-based tracking of per-node WAL/buffer usage
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Stack-based tracking of per-node WAL/buffer usage |
| Дата | |
| Msg-id | da7ad516-37d1-47e5-afae-26a7ef7b60f8@iki.fi обсуждение исходный текст |
| Ответ на | Re: Stack-based tracking of per-node WAL/buffer usage (Lukas Fittl <lukas@fittl.com>) |
| Ответы |
Re: Stack-based tracking of per-node WAL/buffer usage
|
| Список | 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
В списке pgsql-hackers по дате отправления: