Re: Lowering the default wal_blocksize to 4K

Hi,

On Mon, Feb 16, 2026 at 11:13 PM Andres Freund <andres(at)anarazel(dot)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