public inbox for [email protected]
help / color / mirror / Atom feedRe: Lowering the default wal_blocksize to 4K
7+ messages / 5 participants
[nested] [flat]
* Re: Lowering the default wal_blocksize to 4K
@ 2026-02-16 21:13 Andres Freund <[email protected]>
2026-02-17 07:26 ` Re: Lowering the default wal_blocksize to 4K Michael Paquier <[email protected]>
2026-02-17 20:06 ` Re: Lowering the default wal_blocksize to 4K Andrew Pogrebnoi <[email protected]>
0 siblings, 2 replies; 7+ messages in thread
From: Andres Freund @ 2026-02-16 21:13 UTC (permalink / raw)
To: Andy Pogrebnoi <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]>
Hi,
On 2026-02-16 10:04:37 +0200, Andy Pogrebnoi wrote:
> > On Oct 10, 2023, at 02:08, Andres Freund <[email protected]> wrote:
> >
> > Hi,
> >
> > I've mentioned this to a few people before, but forgot to start an actual
> > thread. So here we go:
> >
> > I think we should lower the default wal_blocksize / XLOG_BLCKSZ to 4096, from
> > the current 8192.
>
> I prepared a patch in case we want to move with the default 4kb XLOG_BLCKSZ.
I think we should.
> Regarding reducing the page headers' size, the benefits of 4Kb wal_blocks
> outweight disadvantages of the proportionally bigger header in my opinion.
I agree.
> 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.
> > One thing I noticed is that our auto-configuration of wal_buffers leads to
> > different wal_buffers settings for different XLOG_BLCKSZ, which doesn't seem
> > great.
>
> I don't think it's an issue as wal_buffers are in block units, not bytes. Even
> though the auto-tuned number may change, the total amount of bytes still remains
> the same with different XLOG_BLCKSZ.
Given the way the auto-tuning works, I don't think that's true:
/*
* Auto-tune the number of XLOG buffers.
*
* The preferred setting for wal_buffers is about 3% of shared_buffers, with
* a maximum of one XLOG segment (there is little reason to think that more
* is helpful, at least so long as we force an fsync when switching log files)
* and a minimum of 8 blocks (which was the default value prior to PostgreSQL
* 9.1, when auto-tuning was added).
*
* This should not be called until NBuffers has received its final value.
*/
static int
XLOGChooseNumBuffers(void)
{
int xbuffers;
xbuffers = NBuffers / 32;
if (xbuffers > (wal_segment_size / XLOG_BLCKSZ))
xbuffers = (wal_segment_size / XLOG_BLCKSZ);
if (xbuffers < 8)
xbuffers = 8;
return xbuffers;
}
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.
>
> > For some example numbers, I ran a very simple insert workload with a varying
> > number of clients with both a wal_blocksize=4096 and wal_blocksize=8192
> > cluster, and measured the amount of bytes written before/after.
>
> I've also run some simple tests on my local machine (Ubuntu in Vagrant on M1
> Mac). I run a sysbench write-only load for 20s with different amounts of threads
> (and tables equal to the number of threads num) and measured disk writes with
> iostat. I recreated tables and did a checkpoint before each run. These are my
> results:
>
> 8Kb XLOG_BLCKSZ
> ====
> Threads tps kB_wrtn
> 1 535.34 207288
> 5 1457.24 591708
> 10 1441.85 574700
> 15 823.98 388732
>
> 4Kb XLOG_BLCKSZ
> ====
> Threads tps kB_wrtn
> 1 542.02 153544
> 5 1556.83 393444
> 10 1288.00 339648
> 15 975.32 255708
The reduction in bytes written is rather impressive...
> I will run more benchmarks on proper hardware. For example, interesting what
> happens to performance with >4K writes. But what else do you think has to be
> done to move this patch forward?
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
...
I think we otherwise should just go for it.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K
2026-02-16 21:13 Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
@ 2026-02-17 07:26 ` Michael Paquier <[email protected]>
1 sibling, 0 replies; 7+ messages in thread
From: Michael Paquier @ 2026-02-17 07:26 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Andy Pogrebnoi <[email protected]>; pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]>
On Mon, Feb 16, 2026 at 04:13:37PM -0500, Andres Freund wrote:
> On 2026-02-16 10:04:37 +0200, Andy Pogrebnoi wrote:
>> 8Kb XLOG_BLCKSZ
>> ====
>> Threads tps kB_wrtn
>> 1 535.34 207288
>> 5 1457.24 591708
>> 10 1441.85 574700
>> 15 823.98 388732
>>
>> 4Kb XLOG_BLCKSZ
>> ====
>> Threads tps kB_wrtn
>> 1 542.02 153544
>> 5 1556.83 393444
>> 10 1288.00 339648
>> 15 975.32 255708
>
> The reduction in bytes written is rather impressive...
It's a pretty nice improvement for a change as simple as that, yes.
+1.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K
2026-02-16 21:13 Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
@ 2026-02-17 20:06 ` Andrew Pogrebnoi <[email protected]>
2026-02-18 13:26 ` Re: Lowering the default wal_blocksize to 4K Andy Pogrebnoi <[email protected]>
1 sibling, 1 reply; 7+ messages in thread
From: Andrew Pogrebnoi @ 2026-02-17 20:06 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]>
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
Attachments:
[application/octet-stream] v2-0001-Change-default-wal_blocksize-to-4KB.patch (6.1K, 3-v2-0001-Change-default-wal_blocksize-to-4KB.patch)
download | inline diff:
From 63279ec5776d292ce3bde860ec987726a775dca9 Mon Sep 17 00:00:00 2001
From: Andrew Pogrebnoi <[email protected]>
Date: Fri, 13 Feb 2026 16:14:45 +0200
Subject: [PATCH v2 1/2] Change default wal_blocksize to 4KB
With the current 8KB default, we do more flushes of partially written
buffers, which significantly increases the number of disk writes
compared to 4KB XLOG_BLCKSZ. 4KB pages result in more overhead for
headers, but it is small in comarison with the actual WAL data (~0.29%
of space is headers with 8KB pages, and 0.59% with 4KB).
See more on justification and benchmarks:
https://www.postgresql.org/message-id/20231009230805.funj5ipoggjyzjz6%40awork3.anarazel.de
---
configure | 4 ++--
configure.ac | 4 ++--
doc/src/sgml/config.sgml | 6 +++---
doc/src/sgml/installation.sgml | 4 ++--
doc/src/sgml/wal.sgml | 2 +-
meson_options.txt | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/configure b/configure
index ba293931878..06b50b61d25 100755
--- a/configure
+++ b/configure
@@ -1574,7 +1574,7 @@ Optional Packages:
--with-segsize-blocks=SEGSIZE_BLOCKS
set table segment size in blocks [0]
--with-wal-blocksize=BLOCKSIZE
- set WAL block size in kB [8]
+ set WAL block size in kB [4]
--with-llvm build with LLVM based JIT support
--without-icu build without ICU support
--with-tcl build Tcl modules (PL/Tcl)
@@ -3840,7 +3840,7 @@ if test "${with_wal_blocksize+set}" = set; then :
esac
else
- wal_blocksize=8
+ wal_blocksize=4
fi
diff --git a/configure.ac b/configure.ac
index 412fe358a2f..59678a7dd99 100644
--- a/configure.ac
+++ b/configure.ac
@@ -324,9 +324,9 @@ AC_DEFINE_UNQUOTED([RELSEG_SIZE], ${RELSEG_SIZE}, [
# WAL block size
#
AC_MSG_CHECKING([for WAL block size])
-PGAC_ARG_REQ(with, wal-blocksize, [BLOCKSIZE], [set WAL block size in kB [8]],
+PGAC_ARG_REQ(with, wal-blocksize, [BLOCKSIZE], [set WAL block size in kB [4]],
[wal_blocksize=$withval],
- [wal_blocksize=8])
+ [wal_blocksize=4])
case ${wal_blocksize} in
1) XLOG_BLCKSZ=1024;;
2) XLOG_BLCKSZ=2048;;
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f1af1505cf3..f06de24bd04 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3536,7 +3536,7 @@ include_dir 'conf.d'
but any positive value less than <literal>32kB</literal> will be
treated as <literal>32kB</literal>.
If this value is specified without units, it is taken as WAL blocks,
- that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 8kB.
+ that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 4kB.
This parameter can only be set at server start.
</para>
@@ -3596,7 +3596,7 @@ include_dir 'conf.d'
flushed to disk. If <varname>wal_writer_flush_after</varname> is set
to <literal>0</literal> then WAL data is always flushed immediately.
If this value is specified without units, it is taken as WAL blocks,
- that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 8kB.
+ that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 4kB.
The default is <literal>1MB</literal>.
This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command line.
@@ -12146,7 +12146,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:$libdir'
<para>
Reports the size of a WAL disk block. It is determined by the value
of <literal>XLOG_BLCKSZ</literal> when building the server. The default value
- is 8192 bytes.
+ is 4096 bytes.
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index c903ccff988..6f3409406db 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -1520,7 +1520,7 @@ build-postgresql:
<listitem>
<para>
Set the <firstterm>WAL block size</firstterm>, in kilobytes. This is the unit
- of storage and I/O within the WAL log. The default, 8 kilobytes,
+ of storage and I/O within the WAL log. The default, 4 kilobytes,
is suitable for most situations; but other values may be useful
in special cases.
The value must be a power of 2 between 1 and 64 (kilobytes).
@@ -3047,7 +3047,7 @@ ninja install
<listitem>
<para>
Set the <firstterm>WAL block size</firstterm>, in kilobytes. This is the unit
- of storage and I/O within the WAL log. The default, 8 kilobytes,
+ of storage and I/O within the WAL log. The default, 4 kilobytes,
is suitable for most situations; but other values may be useful
in special cases.
The value must be a power of 2 between 1 and 64 (kilobytes).
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index f3b86b26be9..731b8b6c6f0 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -881,7 +881,7 @@
<filename>pg_wal</filename> under the data directory, as a set of
segment files, normally each 16 MB in size (but the size can be changed
by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
- divided into pages, normally 8 kB each (this size can be changed via the
+ divided into pages, normally 4 kB each (this size can be changed via the
<option>--with-wal-blocksize</option> configure option). The WAL record headers
are described in <filename>access/xlogrecord.h</filename>; the record
content is dependent on the type of event that is being logged. Segment
diff --git a/meson_options.txt b/meson_options.txt
index 6a793f3e479..22d936973d8 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -9,7 +9,7 @@ option('blocksize', type: 'combo',
option('wal_blocksize', type: 'combo',
choices: ['1', '2', '4', '8', '16', '32', '64'],
- value: '8',
+ value: '4',
description: 'WAL block size, in kilobytes')
option('segsize', type: 'integer', value: 1,
--
2.43.0
[application/octet-stream] v2-0002-Fix-XLOG-buffers-auto-tune-for-different-XLOG_BLC.patch (942B, 4-v2-0002-Fix-XLOG-buffers-auto-tune-for-different-XLOG_BLC.patch)
download | inline diff:
From 72a70460d6966f9895ea874514c77a9405859057 Mon Sep 17 00:00:00 2001
From: Andrew Pogrebnoi <[email protected]>
Date: Tue, 17 Feb 2026 21:12:21 +0200
Subject: [PATCH v2 2/2] Fix XLOG buffers auto-tune for different XLOG_BLCKSZ
Before this change, XLOG buffers calculation in relation to
shared_buffers made sense only if XLOG_BLCKSZ the same as BLCKSZ
---
src/backend/access/transam/xlog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 13ec6225b85..d37e85a4077 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -4694,7 +4694,7 @@ XLOGChooseNumBuffers(void)
{
int xbuffers;
- xbuffers = NBuffers / 32;
+ xbuffers = ((NBuffers * BLCKSZ) / XLOG_BLCKSZ) / 32;
if (xbuffers > (wal_segment_size / XLOG_BLCKSZ))
xbuffers = (wal_segment_size / XLOG_BLCKSZ);
if (xbuffers < 8)
--
2.43.0
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K
2026-02-16 21:13 Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
2026-02-17 20:06 ` Re: Lowering the default wal_blocksize to 4K Andrew Pogrebnoi <[email protected]>
@ 2026-02-18 13:26 ` Andy Pogrebnoi <[email protected]>
2026-02-18 16:32 ` Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
2026-03-25 11:10 ` Re: Lowering the default wal_blocksize to 4K John Naylor <[email protected]>
0 siblings, 2 replies; 7+ messages in thread
From: Andy Pogrebnoi @ 2026-02-18 13:26 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]>
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/[email protected]...
---
Cheers,
Andy
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K
2026-02-16 21:13 Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
2026-02-17 20:06 ` Re: Lowering the default wal_blocksize to 4K Andrew Pogrebnoi <[email protected]>
2026-02-18 13:26 ` Re: Lowering the default wal_blocksize to 4K Andy Pogrebnoi <[email protected]>
@ 2026-02-18 16:32 ` Andres Freund <[email protected]>
2026-03-25 14:02 ` Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
1 sibling, 1 reply; 7+ messages in thread
From: Andres Freund @ 2026-02-18 16:32 UTC (permalink / raw)
To: Andy Pogrebnoi <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]>
Hi,
On 2026-02-18 15:26:24 +0200, Andy Pogrebnoi wrote:
> 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.
The fact that the test do pass for msvc (which does not use ccache), but not
for mingw (which uses ccache), does point towards some caching issue.
We've had some caching problems on mingw before.
I don't fully know what's going on, but there clearly is something wrong with
ccache here when using precompiled headers, I can reproduce incomplete
rebuilds with ccache's direct mode on linux, cross building for windows (first
thing I tried). If I rebuild with a changed xlog blocksize, I get *some* cache
hits building the backend, despite pg_config.h having changed.
I think the problem is that ccache seems to not record a dependency to the pch
file in its dependencies if the pch file is included via -include, if the
included header and the header.h.gch file aren't in the same directory . That
leads to the pch file getting rebuilt, but then ccache just uses the older
cached result for the .c file getting built, because it does not recognize it
would need to be rebuilt.
I'll go and report that to the ccache folks.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K
2026-02-16 21:13 Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
2026-02-17 20:06 ` Re: Lowering the default wal_blocksize to 4K Andrew Pogrebnoi <[email protected]>
2026-02-18 13:26 ` Re: Lowering the default wal_blocksize to 4K Andy Pogrebnoi <[email protected]>
2026-02-18 16:32 ` Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
@ 2026-03-25 14:02 ` Andres Freund <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Andres Freund @ 2026-03-25 14:02 UTC (permalink / raw)
To: Andy Pogrebnoi <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]>
Hi,
On 2026-02-18 11:32:28 -0500, Andres Freund wrote:
> On 2026-02-18 15:26:24 +0200, Andy Pogrebnoi wrote:
> > 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.
>
> The fact that the test do pass for msvc (which does not use ccache), but not
> for mingw (which uses ccache), does point towards some caching issue.
>
> We've had some caching problems on mingw before.
>
> I don't fully know what's going on, but there clearly is something wrong with
> ccache here when using precompiled headers, I can reproduce incomplete
> rebuilds with ccache's direct mode on linux, cross building for windows (first
> thing I tried). If I rebuild with a changed xlog blocksize, I get *some* cache
> hits building the backend, despite pg_config.h having changed.
>
>
> I think the problem is that ccache seems to not record a dependency to the pch
> file in its dependencies if the pch file is included via -include, if the
> included header and the header.h.gch file aren't in the same directory . That
> leads to the pch file getting rebuilt, but then ccache just uses the older
> cached result for the .c file getting built, because it does not recognize it
> would need to be rebuilt.
>
> I'll go and report that to the ccache folks.
I did that and forgot to update this thread:
https://github.com/ccache/ccache/issues/1686
Unfortunately not much has happened on that front. But in the course of the
investigation I discovered the gcc flag "fpch-deps". I think we should inject
that in our build, if supported by the compiler. I don't really see a downside
and it does avoid the issue at hand, based on my experiments.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K
2026-02-16 21:13 Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
2026-02-17 20:06 ` Re: Lowering the default wal_blocksize to 4K Andrew Pogrebnoi <[email protected]>
2026-02-18 13:26 ` Re: Lowering the default wal_blocksize to 4K Andy Pogrebnoi <[email protected]>
@ 2026-03-25 11:10 ` John Naylor <[email protected]>
1 sibling, 0 replies; 7+ messages in thread
From: John Naylor @ 2026-03-25 11:10 UTC (permalink / raw)
To: Andy Pogrebnoi <[email protected]>; +Cc: Andres Freund <[email protected]>; pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]>
On Wed, Feb 18, 2026 at 8:26 PM Andy Pogrebnoi
<[email protected]> wrote:
> 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:
FWIW, they just started passing a couple days ago:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F6490
--
John Naylor
Amazon Web Services
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-03-25 14:02 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-16 21:13 Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]>
2026-02-17 07:26 ` Michael Paquier <[email protected]>
2026-02-17 20:06 ` Andrew Pogrebnoi <[email protected]>
2026-02-18 13:26 ` Andy Pogrebnoi <[email protected]>
2026-02-18 16:32 ` Andres Freund <[email protected]>
2026-03-25 14:02 ` Andres Freund <[email protected]>
2026-03-25 11:10 ` John Naylor <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox