CI warnings test for 32 bit, and faster headerscheck
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50344psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 11:28 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50344_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50344_1 && git checkout t50344_1Patchset v1 (message #1) is on t50344_1
Hi,
Today when "adder" choked on a compiler warning, I was annoyed that CI
knew about that[1]https://cirrus-ci.com/task/5357841391812608?logs=build_32#L585 but didn't turn red because only the
CompilerWarnings task fails on warnings and it doesn't test 32 bit.
So here's a patch for that. Tom has already fixed that in master, but
my branch with this change triggered a failure[2]https://cirrus-ci.com/task/5988615321288704 before the fix went
in.
Before adding another ~17s to every CI run (configure: ~9s, make: ~8s)
I figured I should optimise a nearby command that stands out as
wasting a huge amount of time, so that we come out ahead: headerscheck
and cpluspluscheck currently run in ~90s and ~45s respectively. If
you swizzle things around only slightly you can turn on ccache and get
them down to ~20s and ~05s, depending on ccache hit ratio.
The net result of both patches is that CompilerWarnings completes in 4
minutes[3]https://cirrus-ci.com/task/5343255280222208 instead of a bit over 5, assuming ccache doesn't miss.
You could probably squeeze another few seconds out of headerscheck by
changing the loop to generate a script $name.sh for each header, where
each script constructs $name.c and invokes the compiler, and then use
something like find $tmp -name '*.sh' | xargs -P $(nproc) ... to
parallelise all the work, and finally collect all the results from
$tmp/*.output, but at a wild guess that could save only another ~5s or
so. Most of the available speedup comes from not compiling at all.
Hmm, given that configure uses more time than compiling (assuming 100%
ccache hits) and is woefully serial, I wonder what ingredients you'd
need to hash to have bulletproof cache invalidation for a persistent
configure cache, ie that survives between runs. Maybe something like
the output of "apt list --installed" (which lists installed Debian
packages and versions, so any library, tool etc change would
invalidate it, probably just when the CI images gets rebuilt
periodically) would be enough? Maybe we should change these over to
meson anyway, but then the same type of logic probably applies.
[1]: https://cirrus-ci.com/task/5357841391812608?logs=build_32#L585
[2]: https://cirrus-ci.com/task/5988615321288704
[3]: https://cirrus-ci.com/task/5343255280222208
Attachments:
t50344_10001-ci-Use-ccache-for-headerscheck-cpluspluscheck.patchtext/x-patch; charset=US-ASCII; name=0001-ci-Use-ccache-for-headerscheck-cpluspluscheck.patchDownload+16-9
0002-ci-Add-a-warning-check-for-32-bit-builds.patchtext/x-patch; charset=US-ASCII; name=0002-ci-Add-a-warning-check-for-32-bit-builds.patchDownload+33-1
Thomas Munro <thomas.munro@gmail.com> writes:
Hmm, given that configure uses more time than compiling (assuming 100%
ccache hits) and is woefully serial, I wonder what ingredients you'd
need to hash to have bulletproof cache invalidation for a persistent
configure cache, ie that survives between runs.
The buildfarm uses a simple trick that seems to work remarkably well:
if the animal's previous run failed (for any reason) then blow away
the configure cache. Maybe that could be adapted here.
regards, tom lane