Re: Race conditions in 019_replslot_limit.pl
От | Tom Lane |
---|---|
Тема | Re: Race conditions in 019_replslot_limit.pl |
Дата | |
Msg-id | 396915.1648409285@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Race conditions in 019_replslot_limit.pl (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Race conditions in 019_replslot_limit.pl
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > How about the attached variation, which retries (for 15s, with 100ms sleeps) > if there are multiple walsenders, printing the debugging info each time? It'll > still fail the test if later iterations find just one walsender, which seems > the right behaviour for now. We have now four instances of failures with this version of the test, and in every case the second iteration succeeded. Is that enough evidence yet? https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2022-03-27%2017%3A04%3A18 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2022-03-25%2009%3A00%3A09 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes&dt=2022-03-25%2008%3A02%3A05 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2022-03-25%2003%3A00%3A18 I'd like to silence this noise so that we can start tracking lower-probability failure modes, like say these: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=olingo&dt=2022-03-26%2002%3A59%3A03 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2022-03-26%2015%3A53%3A51 regards, tom lane
В списке pgsql-hackers по дате отправления: