Feedback-ID: id4a34324:Fastmail
Date: Wed, 18 Feb 2026 11:32:28 -0500
From: Andres Freund <andres@anarazel.de>
To: Andy Pogrebnoi <andrew.pogrebnoi@percona.com>
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>
Subject: Re: Lowering the default wal_blocksize to 4K
Message-ID: <3r2far37ustqtoy62i4l2et5y46thkztzeyrwharxk2fzllndw@kvztwwijbcez>
References: <20231009230805.funj5ipoggjyzjz6@awork3.anarazel.de>
 <E25A9AD2-EAD3-4372-AFD2-2627E4D5E3C5@percona.com>
 <x56pxq6jpuftn6ear3uwbz5tyb4r37itv5zetvcucq3td57apc@yq7jyka7tszv>
 <CA+aWR11Gvz4RvPaBx1kfpTx2QxpNW46Yv120dDcUA93UbYcxrg@mail.gmail.com>
 <CA+aWR11mKA=kFGxX++6uMAhhqzRPU72ktd9TnhbD3O8OnR_Org@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+aWR11mKA=kFGxX++6uMAhhqzRPU72ktd9TnhbD3O8OnR_Org@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/3r2far37ustqtoy62i4l2et5y46thkztzeyrwharxk2fzllndw%40kvztwwijbcez>
Precedence: bulk

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