Re: failures in t/031_recovery_conflict.pl on CI
От | Andres Freund |
---|---|
Тема | Re: failures in t/031_recovery_conflict.pl on CI |
Дата | |
Msg-id | 20220503191305.htuzje6ldmic7skk@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
RE: failures in t/031_recovery_conflict.pl on CI |
Список | pgsql-hackers |
Hi, On 2022-05-03 14:23:23 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > >> So it's almost surely a timing issue, and your theory here seems plausible. > > > Unfortunately I don't think my theory holds, because I actually had added a > > defense against this into the test that I forgot about momentarily... > > Oh, hm. I can try harder to repro it. I've now reproduced it a couple times here running under rr, so it's probably not worth putting too much effort into that. 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. My current problem is that I'm running into some IPC::Run issues (bug?). I get "ack Broken pipe:" iff I add "SELECT pg_sleep(1);" after "-- wait for lock held by prepared transaction" It doesn't happen without that debugging thing, but it makes me worried that it's something that'll come up in random situations. It looks to me like it's a bug in IPC::Run - with a few changes I get the failure to happen inside pump_nb(), which seems like it shouldn't error out just because the child process exited... I *think* it might not happen without the sleep. But I'm not at all confident. In general I'm kinda worried on how much effectively unmaintained perl stuff we're depending :( Greetings, Andres Freund
Вложения
В списке pgsql-hackers по дате отправления: