Feedback-ID: id4a34324:Fastmail
Date: Wed, 25 Mar 2026 10:02:08 -0400
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: <phsrssp75npoyalqsolcd7fmnmlbzbmquc2p7w7mqjlw7432jk@bzskz3luyjvb>
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>
 <3r2far37ustqtoy62i4l2et5y46thkztzeyrwharxk2fzllndw@kvztwwijbcez>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3r2far37ustqtoy62i4l2et5y46thkztzeyrwharxk2fzllndw@kvztwwijbcez>
Archived-At: 
 <https://www.postgresql.org/message-id/phsrssp75npoyalqsolcd7fmnmlbzbmquc2p7w7mqjlw7432jk%40bzskz3luyjvb>
Precedence: bulk

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