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

Hi,

On Mon, Nov 9, 2026 at 8:14 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> On Mon, Nov 09, 2026 at 09:51:13PM -0500, shihao zhong wrote:
> > Reading v1, I think the pgstat_backend.c part makes the leader drop
> > the WAL of its workers from pg_stat_get_backend_wal(). A worker drops
> > its own backend stats entry when it exits. So on master the leader
> > entry is the only place that counts that WAL, and it counts it once.
> >
> > I checked it with your parallel VACUUM case. On master I get
> >
> > actual_wal_bytes | pg_stat_wal_bytes | leader_backend_wal_bytes
> > 95926320 | 128524537 | 97581712
> >
> > With v1 I get
> >
> > actual_wal_bytes | pg_stat_wal_bytes | leader_backend_wal_bytes
> > 97900592 | 97581712 | 66638887
> >
> > So pg_stat_wal is right with v1, but the leader entry lost about
> > 31MB. Is leader only intended here, to match pg_stat_get_backend_io()?
>
> Yeah, I think so. The documentation says that pg_stat_get_backend_wal() reports
> statistics about the backend with the specified process ID, so worker's WAL should
> not be attributed to the leader.
>
> So I think the pgstat_backend.c changes should stay, but the commit message
> should probably clarify that this part fixes attribution rather than double
> counting.

Yeah - this is a bit of an odd case, since in practice you won't be
able to call pg_stat_get_backend_wal() on a worker, since the workers
are too short-lived.

I'm leaning towards Bertrand's point to leave this as is, so we match
what the documentation already says, and clarify in the commit
message.

In the future we could invent a mechanism to get aggregated parallel
worker activity for a given leader PID in a separate statistics kind.
An updated patch I'm drafting for stack-based instrumentation keeps
the worker imported statistics cleanly separated (in the per-query
Instrumentation struct), so it would be an easy extension on top of
that.

Thanks,
Lukas

--
Lukas Fittl