| 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: | Whole Thread | Raw Message | 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 |