Re: Fix cumulative WAL statistics double-counting from parallel workers

On Tue, Nov 3, 2026 at 11:32 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Nov 03, 2026 at 04:56:43PM -0800, Lukas Fittl wrote:
> > The only way to avoid extra work in InstrStopNode is to have a global
> > that represents what pgWalUsage currently is (leader + worker), but
> > maybe I'm missing something in your argument?
>
> Speaking HEAD-only here, I still think that accumulating the worker
> numbers in pgWalUsage is an abuse of the facility. I'm finding this
> point to be what itches me the most regarding this thread.

+1 on that, I'd love to find a way to avoid that.

I think ultimately our problem is that we need some way to "attach"
the worker WAL/buffer activity to the right executor node (i.e. the
one that caused a nested statement to be called that had worker
activity), and that node then needs to be able to accumulate that
activity upwards to parent nodes, potentially other parent statements,
and the query-level instrumentation, all without affecting the global
top value like it does today.

There is some overlap here with the stack-based instrumentation work
(which has a more explicit accumulation pass to propagate information
upwards on query end, vs relying on the nested nature of
InstrStopNode), and with that in place we might be able to devise a
design where we just remember the extra instrumentation on the current
stack entry, and then can keep it separated, avoiding mixing it up
with the leader-only global. If helpful I can prototype that to
illustrate it.

That said, I'm still leaning towards going with one of the "simpler"
approaches I sketched out, FWIW, just because it seems less ambitious
in terms of overall code change.

Thanks,
Lukas

--
Lukas Fittl