From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: 15beta1 test failure on mips in isolation/expected/stats |
Date: | 2022-05-20 03:58:24 |
Message-ID: | 265570.1653019104@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2022-05-19 21:42:31 -0400, Tom Lane wrote:
>> Even more interesting, the repeatability varies with the settings
>> of max_connections and max_prepared_transactions.
> That is indeed quite odd.
>> At low values (resp. 20 and 0) I've not been able to make it happen at all,
>> but at 100 and 2 it happens circa three times out of four.
> Is this the only permutation that fails?
No, but those values definitely seem to affect the probability of
failure. I just finished a more extensive series of runs, and got:
successes/tries with max_connections/max_prepared_transactions:
5/5 OK with 20/2
5/5 OK with 100/0
3/5 OK with 100/2
4/5 OK with 200/2
5/6 OK with 100/10
5/6 OK with 50/2
6/10 OK with 100/2
It seems like the probability decreases again if I raise either
number further. So I'm now guessing that this is purely a timing
issue and that somehow 100/2 is near the sweet spot for hitting
the timing window. Why those settings would affect pgstats at
all is unclear, though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-05-20 03:58:29 | Re: Build-farm - intermittent error in 031_column_list.pl |
Previous Message | Andres Freund | 2022-05-20 03:47:27 | Re: 15beta1 test failure on mips in isolation/expected/stats |