public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Lukas Fittl <[email protected]>
To: Zsolt Parragi <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Peter Smith <[email protected]>
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
Date: Mon, 23 Mar 2026 16:41:18 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAP53PkyEPa=aFZrd0crLgRJm1KGS0ykJ+1i2CwDfDNFKpCc+XQ@mail.gmail.com>
References: <CAP53PkzdBK8VJ1fS4AZ481LgMN8f9mJiC39ZRHqkFUSYq6KWmg@mail.gmail.com>
<CAP53PkyOvXC7pWAiamvWth_JNeb=isrxX+PJT0pw_Hw5Czzf+Q@mail.gmail.com>
<CAP53PkzGbyeJMLDAcvMRgzXPXYsYXZr3SBg0UwhfkYjqu8oK_g@mail.gmail.com>
<CAP53PkxrmpECzVFpeeEEHDGe6u625s+YkmVv5-gw3L_NDSfbiA@mail.gmail.com>
<CAN4CZFMon7XcTv+PKXB_ANUJ86k9VmJnx7BoW2q1m5Z2QQVZQw@mail.gmail.com>
<CAP53PkxAS-rpp0kcOjg--q5NVNnRC+0kh1+gB8gnRNqacTqF5A@mail.gmail.com>
<CAN4CZFNuxMqnmtujzemZ1i7hzYkaLD+BWPNq8tFXoPWp5R4How@mail.gmail.com>
<CAP53PkxFP7i7-wy98ZmEJ11edYq-RrPvJoa4kzGhBBjERA4Nyw@mail.gmail.com>
<[email protected]>
<CAN4CZFOdYhRfecTJjJZCwHtS-gzpSJ16YLQ7Wh0bXrg0=8keOw@mail.gmail.com>
<CAP53PkxfVnQpcjrwegamPKdyy3RExXXeXNQW1ZWWtr=JtNsLNQ@mail.gmail.com>
<CAN4CZFMk10YCixVTnt+uBaUH_BH1R=Er-PnPs2YDBhFjuE3K-Q@mail.gmail.com>
<CAP53Pkwdg7Pmf+OqUBu4_SKgxEH3oosSrxxMc4v=mCqMUB049A@mail.gmail.com>
<CAP53PkyEPa=aFZrd0crLgRJm1KGS0ykJ+1i2CwDfDNFKpCc+XQ@mail.gmail.com>
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
view thread (44+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox