Message-ID: <da7ad516-37d1-47e5-afae-26a7ef7b60f8@iki.fi>
Date: Mon, 23 Mar 2026 16:41:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
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>
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>
 <06086cb4-881b-4f5a-96af-f275220ff52d@vondra.me>
 <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>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CAP53PkyEPa=aFZrd0crLgRJm1KGS0ykJ+1i2CwDfDNFKpCc+XQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/da7ad516-37d1-47e5-afae-26a7ef7b60f8%40iki.fi>
Precedence: bulk

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