From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: CI warnings test for 32 bit, and faster headerscheck
In-reply-to: <CA+hUKGJjQyZUvcu6udk5OKz5rnaF4a_hm5nb_VtZHYMH+vsN0g@mail.gmail.com>
References: <CA+hUKGJjQyZUvcu6udk5OKz5rnaF4a_hm5nb_VtZHYMH+vsN0g@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Thu, 03 Oct 2024 18:56:24 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <301303.1727964960.1@sss.pgh.pa.us>
Date: Thu, 03 Oct 2024 10:16:00 -0400
Message-ID: <301304.1727964960@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/301304.1727964960%40sss.pgh.pa.us>
Precedence: bulk

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