public inbox for [email protected]  

help / color / mirror / Atom feed

From: 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, 25 Mar 2026 10:02:08 -0400
Message-ID: <phsrssp75npoyalqsolcd7fmnmlbzbmquc2p7w7mqjlw7432jk@bzskz3luyjvb> (raw)
In-Reply-To: <3r2far37ustqtoy62i4l2et5y46thkztzeyrwharxk2fzllndw@kvztwwijbcez>
References: <[email protected]>
	<[email protected]>
	<x56pxq6jpuftn6ear3uwbz5tyb4r37itv5zetvcucq3td57apc@yq7jyka7tszv>
	<CA+aWR11Gvz4RvPaBx1kfpTx2QxpNW46Yv120dDcUA93UbYcxrg@mail.gmail.com>
	<CA+aWR11mKA=kFGxX++6uMAhhqzRPU72ktd9TnhbD3O8OnR_Org@mail.gmail.com>
	<3r2far37ustqtoy62i4l2et5y46thkztzeyrwharxk2fzllndw@kvztwwijbcez>

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

view thread (7+ messages)

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: <phsrssp75npoyalqsolcd7fmnmlbzbmquc2p7w7mqjlw7432jk@bzskz3luyjvb>

* 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