From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: failures in t/031_recovery_conflict.pl on CI |
Date: | 2022-05-03 19:13:05 |
Message-ID: | 20220503191305.htuzje6ldmic7skk@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-05-03 14:23:23 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-timing-issue-in-deadlock-recovery-conflict-test.patch | text/x-diff | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2022-05-03 19:40:04 | Re: bogus: logical replication rows/cols combinations |
Previous Message | Peter Eisentraut | 2022-05-03 19:06:12 | Re: [PATCH] Log details for client certificate failures |