public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andres Freund <[email protected]>
To: Andy Pogrebnoi <[email protected]>
Cc: [email protected]
Cc: Heikki Linnakangas <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Subject: Re: Lowering the default wal_blocksize to 4K
Date: Wed, 18 Feb 2026 11:32:28 -0500
Message-ID: <3r2far37ustqtoy62i4l2et5y46thkztzeyrwharxk2fzllndw@kvztwwijbcez> (raw)
In-Reply-To: <CA+aWR11mKA=kFGxX++6uMAhhqzRPU72ktd9TnhbD3O8OnR_Org@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<x56pxq6jpuftn6ear3uwbz5tyb4r37itv5zetvcucq3td57apc@yq7jyka7tszv>
<CA+aWR11Gvz4RvPaBx1kfpTx2QxpNW46Yv120dDcUA93UbYcxrg@mail.gmail.com>
<CA+aWR11mKA=kFGxX++6uMAhhqzRPU72ktd9TnhbD3O8OnR_Org@mail.gmail.com>
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
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Lowering the default wal_blocksize to 4K
In-Reply-To: <3r2far37ustqtoy62i4l2et5y46thkztzeyrwharxk2fzllndw@kvztwwijbcez>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox