Horton
Menu

Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas@vondra.me>
Cc: Alexander Lakhin <exclusion@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-06T16:08:30Z
Lists: pgsql-hackers 
Tomas Vondra <tomas@vondra.me> writes:
> On 12/6/25 10:00, Alexander Lakhin wrote:
>> though I can't see timeout-related changes in [4], probably something was
>> changed in the environment during the upgrade...

> Yeah, I noticed that too. But I have no idea what could have changed or
> why - the only thing I updated is the buildfarm client :-(

Comparing the configuration dumps from avocet's last successful run
and its latest, I see that last successful shows

                  'wait_timeout' => 0
 
but the failing run shows

                  'wait_timeout' => undef

Per the comments in the sample config file:

	# max time in seconds allowed for a single branch run
	# undef means default, which is 4 hours. For unlimited specify 0
	wait_timeout => undef,

I'd actually recommend a setting of a couple of days for these
animals, rather than "0".  We've been known to get BF animals
into infinite loops, and if you use "0" then you will need to
clean up such mistakes manually.

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make stats_ext test faster under cache-clobbering test conditions.

  2. Re-allow using statistics for bool-valued functions in WHERE.

  3. Build out the planner support function infrastructure.