Re: failures in t/031_recovery_conflict.pl on CI
От | Andres Freund |
---|---|
Тема | Re: failures in t/031_recovery_conflict.pl on CI |
Дата | |
Msg-id | 20220506030927.6qehktk6bodv4ft3@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: failures in t/031_recovery_conflict.pl on CI (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: failures in t/031_recovery_conflict.pl on CI
|
Список | pgsql-hackers |
Hi, On 2022-05-05 22:07:40 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Attached is a fix for the test that I think should avoid the problem. Couldn't > > repro it with it applied, under both rr and valgrind. > > May I ask where we're at on this? Next week's back-branch release is > getting uncomfortably close, and I'm still seeing various buildfarm > animals erratically failing on 031_recovery_conflict.pl. Yea, sorry. I had crappy internet connectivity / device access for the last few days, making it hard to make progress. Looks like the problems are gone on HEAD at least. > Should we just remove that test from the back branches for now? That might be the best course, marking the test as TODO perhaps? Unfortunately a pg_ctl reload isn't processed reliably by the time the next test steps execute (saw that once when running in a loop), and a restart causes other problems (throws stats away). > Also, it appears that the back-patch of pump_until failed to remove > some pre-existing copies, eg check-world in v14 now reports > Subroutine pump_until redefined at t/013_crash_restart.pl line 248. > Subroutine pump_until redefined at t/022_crash_temp_files.pl line 272. > > I didn't check whether these are exact duplicates. They're not quite identical copies, which is why I left them in-place. But the warnings clearly make that a bad idea. I somehow mis-extrapolated from Cluster.pm, where it's not a problem (accessed via object). I'll remove them. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: