Re: log_checkpoints: count WAL segment creations from all processes

Hi all,

On Fri, Jun 19, 2026 at 5:38 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> On Wed, Mar 25, 2026 at 9:11 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> >
> > Hi Japin,
> >
> > Thanks for looking into this.
> >
> > On Tue, Mar 24, 2026 at 10:01 PM Japin Li <japinli(at)hotmail(dot)com> wrote:
> > >
> > >
> > > Hi, Xuneng
> > >
> > > On Tue, 24 Mar 2026 at 19:17, Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > > > Hi Zsolt,
> > > >
> > > > On Tue, Mar 24, 2026 at 1:55 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> > > >
> > > > Hello!
> > > >
> > > > This is a simple patch, but shouldn't it include at least some basic
> > > > tests verifying the new behavior?
> > > >
> > > > Thanks for looking into this. I've added a test for it. Please take a look.
> > >
> > > Thanks for updating the patch. A few comments on v2:
> > >
> > > 1.
> > > + (The probes listed next fire in sequence during checkpoint processing.)
> > > + arg0 is the number of buffers written. arg1 is the total number of
> > >
> > > These changes seem unnecessary. Additionally, there appears to be an
> > > indentation issue.
> >
> > Yeah, I've removed these and fixed the indentation issue.
> >
> > > 2.
> > > + current = pg_atomic_read_u64(&XLogCtl->walSegmentsCreated);
> > > + CheckpointStats.ckpt_segs_added = (int)
> > > + (current - XLogCtl->walSegsCreatedLastCheckpoint);
> > > + XLogCtl->walSegsCreatedLastCheckpoint = current;
> > >
> > > Is integer overflow a concern here? It seems unlikely in practice.
> >
> > I don’t think overflow is a concern here, but it might still be
> > helpful to add some comments to mention it.
> >
>
> v4 fixed the inaccurate overflow numbers in comments.
>

I reviewed and tested v4 of the patch on the current tree branch. The
patch did not apply cleanly due to a conflict in meson.build, which
was caused by changes in the recovery test list on the current master.
I resolved it by keeping both test entries (053_wal_segs_added.pl and
053_standby_login_event_trigger.pl). Then the patch was built and
installed successfully. Before testing, I enabled log_checkpoints and
generated WAL activity using CREATE TABLE AS SELECT generate_series
workload and pgbench (-c 20 -j 4 -T 120). Before applying the patch,
checkpoint logs consistently reported: "0 WAL file(s) added" despite
substantial WAL activity, with checkpoint distances around 500 MB
between checkpoints while after applying the patch, the first
checkpoint reported as: "64 WAL file(s) added, 1 removed, 32 recycled"
for a checkpoint distance of approximately 536 MB. This indicates that
WAL segment creations are now being accounted for beyond the previous
PreallocXlogFiles() path. Subsequent checkpoints reported small values
(0–1 WAL files added), while continuing to recycle existing WAL
segments. This behavior appears reasonable, as PostgreSQL was largely
able to satisfy WAL demand through recycling once a sufficient WAL
pool had been established. I also verified the WAL directory state
during testing. The number of WAL segment files changed from 64 to 61
after additional workload and checkpoints, confirming that WAL segment
creation counts should not be expected to match the number of files
currently present in pg_wal, since removal and recycling occur
independently. Based on the observed behavior, the patch appears to
fix the under-reporting of WAL segment creation counts in checkpoint
log output and behaves as expected during sustained WAL generation
workloads. Also, it would be better to expose wal_segments_created
through pg_stat_checkpointer. This would make the information
available for monitoring and capacity planning without requiring log
parsing and could provide additional value for administrators tracking
WAL growth patterns.

Regards,
Solai