Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness
Date
Msg-id 50180873-DAD9-483C-8FD8-48F62FD32A4A@amazon.com
Whole thread Raw
In response to Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 7/26/21, 5:48 PM, "Andres Freund" <andres@anarazel.de> wrote:
> On 2021-07-26 20:27:21 +0000, Bossart, Nathan wrote:
>> +1.  I was confused by this when working on a WAL pre-allocation
>> patch [0].  Perhaps it could be replaced by a new parameter and a new
>> field in pg_stat_wal.  How about something like log_wal_init_interval,
>> where the value is the minimum amount of time between reporting the
>> number of WAL segments created since the last report?
>
> Why not just make the number in log_checkpoints accurate? There's no
> point in the current number, so we don't need to preserve it...

My understanding is that the statistics logged for log_checkpoints are
just for that specific checkpoint.  From that angle, the value for the
number of WAL files added is technically correct.  Checkpoints will
only ever create zero or one new files via PreallocXlogFiles().  If we
also added all the segments created outside of the checkpoint, the
value for "added" would go from meaning "WAL files created by this
checkpoint" to "WAL files creates since the last checkpoint."  That's
probably less confusing than what's there today, but it's still
slightly different than all the other log_checkpoints stats.

Nathan


pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Slim down integer formatting
Next
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum