Re: Lowering the default wal_blocksize to 4K

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