Hi Xuneng, Thank you for working on this. I've reviewed the v4 patch and wanted to discuss the counter design approach before diving into implementation details.
The patch uses two fields for tracking: a cumulative atomic counter (walSegmentsCreated) that grows since startup, and a non-atomic baseline (walSegsCreatedLastCheckpoint). At each checkpoint, you compute ckpt_segs_added as the difference between the current counter and the baseline, then update the baseline for the next interval. I'd like to propose a simpler alternative using a single reset counter. Instead of maintaining cumulative state, we could use pg_atomic_exchange_u64 to atomically read and reset the counter in one operation. This would require only one shared memory field and eliminate the need for baseline tracking and subtraction arithmetic. This approach would be simpler (one field instead of two, no arithmetic, no baseline maintenance), follow PostgreSQL's pattern of not keeping unused cumulative state, provide true atomicity (pg_atomic_exchange_u64 reads and resets in one indivisible operation), and save 8 bytes of shared memory. Could you share your reasoning for the cumulative counter approach? I may be missing a use case. If there's no strong reason for the cumulative value, would you consider the simpler reset-based approach? Best Regards, Nitin Jadhav Azure Database for PostgreSQL Microsoft On Sun, May 17, 2026 at 2:41 PM Hüseyin Demir <[email protected]> wrote: > > Hi, > > Thanks for the patch. The idea is good and can we introduce a new > counter to pg_stat_checkpointer ? For example, we can add > wal_segments_created to this view and it would be useful for capacity > planning and load estimations. > > Additionally I have a few questions > > - Should we make walSegsCreatedLastCheckpoint atomic ? In the future > we can also add this to views maybe. It's an auxiliary suggestion. > - ckpt_segs_added is defined as int but overflow threshold is 2^32 in > comments. Shouldn't we use 2^31 for int ? > - Maybe it's a bad idea but should we extend the tests with the > wal_level set to minimal ? > > PS: I created a patch to expose wal_segments_created to > pg_stat_checkpointer view. You can review it and enhance your patch if > you need. I created it to explain my idea better so it can be > destroyed after your review. But I couldn't create a patch for > preceding questions. > > Regards, > Demir.
