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 by date:
Соглашаюсь с условиями обработки персональных данных
