Re: Lowering the default wal_blocksize to 4K

Andy Pogrebnoi <andrew.pogrebnoi@percona.com>

From: Andy Pogrebnoi <andrew.pogrebnoi@percona.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: 2026-02-18T13:26:24Z
Lists: pgsql-hackers
Hi,

The Windows tests are failing on `Assert("check_GUC_init(hentry->gucvar)")`
for wal_writer_flush_after [1]. It doesn't make much sense to me as both
load- and C-value for the wal_writer_flush_after GUC are the same constant:

src/backend/utils/misc/guc_parameters.dat:
{ name => 'wal_writer_flush_after', type => 'int', context => 'PGC_SIGHUP',
group => 'WAL_SETTINGS',
  short_desc => 'Amount of WAL written out by WAL writer that triggers a
flush.',
  flags => 'GUC_UNIT_XBLOCKS',
  variable => 'WalWriterFlushAfter',
  boot_val => 'DEFAULT_WAL_WRITER_FLUSH_AFTER',
  min => '0',
  max => 'INT_MAX',
},

src/include/postmaster/walwriter.h:
int WalWriterFlushAfter = DEFAULT_WAL_WRITER_FLUSH_AFTER;

This constant was introduced to fix the same issue [2], but I suppose no
one checked Windows builds. Windows clearly has an old 8kB value for
WalWriterFlushAfter during the check. I suppose it is something with the
CI/build. But I have zero experience with building anything for Windows, so
any tips on where to look are welcome.

*And apologies for the dreadful formatting in my previous email; the client
plays tricks on me after I hit Send.

[1] https://cirrus-ci.com/task/6286650038288384?logs=test_world#L2728-L2729
[2]
https://www.postgresql.org/message-id/CA+hUKGLNmLV=VrT==5MqnbARgx2ifRSFtdd8ofdfrdSLL3yv5A@mail.gmail.com

---
Cheers,
Andy

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. During online checkpoints, insert XLOG_CHECKPOINT_REDO at redo point.