On Wed, Nov 4, 2026 at 2:22 PM Michael Paquier <[email protected]> wrote: > > On Wed, Nov 04, 2026 at 12:50:33PM -0800, Lukas Fittl wrote: > > Ack, thanks for chiming in - I'll await for Michael to take another > > look but will otherwise post an updated v2 addressing Bertrand's > > comments, staying on the (1) approach. > > Is that referring to the patch set posted here? I mean here: > https://www.postgresql.org/message-id/CAP53Pkwd6Gd4OL6cgh449wtdznWitz_V%3D-PRoswLHOzsMbcftA%40mail.gmail.com
No, sorry if that got confusing - this is referencing the original patch on this thread, which is the "simple" way of solving the immediate problem (pg_stat_wal overcounting) by keeping a separate accumulation of the statistics that were imported from the worker, and then subtracting that when reporting to the cumulative stats system. Basically the original approach on this thread here is ugly, but it works, doesn't have performance impact, and is easy to reason about. I'm advocating for getting this in to both master and the back branches, and then separately work on solving it more elegantly, which in my perspective makes most sense in combination with the stack-based instrumentation thread you linked. > > The stack-based instrumentation series [1] actually has two prep > > patches that drop the remaining direct users of pgBufferUsage to > > further clean up the API (it keeps a user of pgWalUsage in > > pruneheap.c, which is a special case), after which I think the main > > unsolved use case is how we want the instrumentation fed into the > > cumulative stats system without directly accessing a global variable. > > Do the suggestions on the other thread make what is presented on this > thread irrelevant? I don't like much what's been sent now on this > thread, but I could see myself like something sent on the other thread > if my concerns about the numbers and the way they're aggregated for > the leader and workers are lifted. I have not looked at what you have > sent on the other thread, just what you have sent on this thread. As it stands the other thread on stack-based instrumentation does not solve this problem (yet), but it contains the prerequisite infrastructure that's needed, because it avoids the global counters (pgWalUsage, etc) that move forward as activity happens, and instead records into the current stack entry that then accumulates into the parent separately on query end. I'm working on an updated version for that thread that illustrates how that helps us with the problem at hand. FWIW, the prep work I was referring to was specifically in regards to making the API contract clearer, and avoiding people looking at pgBufferUsage/pgWalUsage directly - I think that's a no-brainer that we should get in in any case. Thanks, Lukas -- Lukas Fittl
