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 →
-
During online checkpoints, insert XLOG_CHECKPOINT_REDO at redo point.
- afd12774ae89 17.0 landed