| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Lukas Fittl <lukas(at)fittl(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ahmed Gouda <gouda0x(at)gmail(dot)com>, Bernd Reiß <bd_reiss(at)gmx(dot)at> |
| Subject: | Re: Fix cumulative WAL statistics double-counting from parallel workers |
| Date: | 2026-11-10 02:51:13 |
| Message-ID: | CAGRkXqQskUo2s539Wk+iYav1mp=cDcMPT+ofVXHFRE4HTRxfBQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Lukas,
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()?
If not, maybe the pgstat_backend.c part can be left out.
Thanks,
Shihao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nisha Moond | 2026-11-10 02:54:31 | Re: Crashes on a partition whose concurrent detach never finished |
| Previous Message | Tender Wang | 2026-11-10 02:06:37 | Backend crash in expanded_record_info functions |