MIME-Version: 1.0
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>
 <da7ad516-37d1-47e5-afae-26a7ef7b60f8@iki.fi>
 <CAN4CZFOUTHdXuEAwrST8ueDxGJRe69zVgeVAY0osTjVkRZi_Lw@mail.gmail.com>
 <CAP53Pkx+HZ2OSGDHmNgSDisXdjGp4KFygaX+GaQcFEuXHRXg=g@mail.gmail.com>
 <CAP53PkznofNg+ii363QQGoje30nhssuSz_hV5U4YANAt-Yr_Yg@mail.gmail.com>
 <CAN4CZFPJOG0PeLOBmZZvkY+aeZJ0+swjNjUabaeeimWxbtN41A@mail.gmail.com>
In-Reply-To: 
 <CAN4CZFPJOG0PeLOBmZZvkY+aeZJ0+swjNjUabaeeimWxbtN41A@mail.gmail.com>
From: Lukas Fittl <lukas@fittl.com>
Date: Tue, 24 Mar 2026 22:34:29 -0700
Message-ID: 
 <CAP53PkwTxo5R8_x76PmixXBV2YBGGf+7miRP28Asr7u-CLhQfA@mail.gmail.com>
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>,
 Tomas Vondra <tomas@vondra.me>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Peter Smith <smithpb2250@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAP53PkwTxo5R8_x76PmixXBV2YBGGf%2B7miRP28Asr7u-CLhQfA%40mail.gmail.com>
Precedence: bulk

Hi Zsolt,

On Tue, Mar 24, 2026 at 3:59=E2=80=AFPM Zsolt Parragi <zsolt.parragi@percon=
a.com> wrote:
> I like the new approach, but doesn't `EXPLAIN (BUFFERS)` leak some
> memory because the resource owner isn't registered on that path? It
> seems to be visible with pg_log_backend_memory_contexts.

Ah, yes, good catch! Its nice how the separate memory context makes
this very clear now.

I think this was actually an existing problem that only surfaced now.
The issue is that EXPLAIN (BUFFERS) will allocate the per-query
instrumentation, but not actually use it, since the buffer tracking is
only relevant for planning, which has its own instrumentation. I can
fix this locally by adding the following to FreeExecutorState:

    /*
     * Make sure the instrumentation context gets freed. This usually gets
     * re-parented under the per-query context in InstrQueryStopFinalize, b=
ut
     * that won't happen during EXPLAIN (BUFFERS) since ExecutorFinish neve=
r
     * gets called, so we would otherwise leak it in TopMemoryContext.
     */
    if (estate->es_instrument && estate->es_instrument->instr.need_stack)
        MemoryContextDelete(estate->es_instrument->instr_cxt);

I'll include this in the next revision unless I come up with a better
idea. FWIW, I also considered just not setting INSTRUMENT_BUFFERS in
ExplainOnePlan unless ANALYZE is active, but I think there might be
other cases where that doesn't work as expected, so I think the
explicit delete is better.

>
>  #define INSTR_BUFUSAGE_ADD(fld,val) do { \
> - pgBufferUsage.fld +=3D val; \
> + instr_stack.current->bufusage.fld +=3D val; \
>
>  #define INSTR_WALUSAGE_ADD(fld,val) do { \
>   pgWalUsage.fld +=3D val; \
> + instr_stack.current->walusage.fld +=3D val; \
>
> Nitpick, but these could use +=3D (val)

Ack, makes sense - I'll adjust in the next revision.

I'll give it a day or so for further feedback before posting the next updat=
e.

Thanks,
Lukas

--=20
Lukas Fittl