Hi, On Mon, Feb 16, 2026 at 11:13 PM Andres Freund <[email protected]> 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
v2-0001-Change-default-wal_blocksize-to-4KB.patch
Description: Binary data
v2-0002-Fix-XLOG-buffers-auto-tune-for-different-XLOG_BLC.patch
Description: Binary data
