Hi all, On Fri, Jun 19, 2026 at 5:38 PM Xuneng Zhou <[email protected]> wrote: > > On Wed, Mar 25, 2026 at 9:11 AM Xuneng Zhou <[email protected]> wrote: > > > > Hi Japin, > > > > Thanks for looking into this. > > > > On Tue, Mar 24, 2026 at 10:01 PM Japin Li <[email protected]> wrote: > > > > > > > > > Hi, Xuneng > > > > > > On Tue, 24 Mar 2026 at 19:17, Xuneng Zhou <[email protected]> wrote: > > > > Hi Zsolt, > > > > > > > > On Tue, Mar 24, 2026 at 1:55 PM Zsolt Parragi > > > > <[email protected]> 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
