Re: log_checkpoints: count WAL segment creations from all processes

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 <huseyin(dot)d3r(at)gmail(dot)com> 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.