On Mon, Feb 16, 2026 at 11:13 PM Andres Freund <
andres@anarazel.de> wrote:
> Hi,
>
> On 2026-02-16 10:04:37 +0200, Andy Pogrebnoi wrote:
> > Since we recycle WAL segments, the added size won't go to the disk usage but
> > rather cause a bit more freqent segment.
>
> I don't think that's a valid argument though, how much WAL needs to be
> archived is a relevant factor.
Yes, indeed.
> If NBuffers / 32 < wal_segment_size / XLOG_BLCKSZ, the chosen xbuffers value
> does not depend on XLOG_BLCKSZ.
>
> To me the code only makes sense if you assume that NBuffers / 32 gives you a
> value in the same domain as data blocks, otherwise NBuffers / 32 is not the
> approximation of %3 that the comment talks about.
>
>
> I think the code just needs to be fixed to multiply NBuffers * BLCKSZ and then
> divide that by XLOG_BLCKSZ.
You are right, my bad, fixed (v2-0002).
> I think the auto-tuning bit above needs to be fixed, and it's probably worth
> manually testing a pg_upgrade from 8kB XLOG_BLCKSZ to 4kB. It should work, but
pg_upgrade ran with no issues, and the database started with the new (4kB) XLOG_BLCKSZ
I also found and fixed some more mentions of 8kB as the default for XLOG_BLCKSZ in the
documentation (v2-0001).
---
Cheers,
Andy
