Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS

Tomas Vondra <tomas@vondra.me>

From: Tomas Vondra <tomas@vondra.me>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Lakhin <exclusion@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-06T16:39:31Z
Lists: pgsql-hackers
On 12/6/25 17:08, Tom Lane wrote:
> 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.
> 

I'll try, but that's just the default in v20 of the buildfarm client (I
always get the new .sample and update it with the necessary changes,
keeping all the defaults).

regards

-- 
Tomas Vondra




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.