From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: random isolation test failures |
Date: | 2011-09-27 19:59:13 |
Message-ID: | 28334.1317153553@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of mar sep 27 01:11:39 -0300 2011:
>> Hmm, is that really an appropriate fix? I'm worried that it might mask
>> event-ordering differences that actually are significant.
> In the attached, it only affects the case where there is one blocking
> command and another command that unblocks it; this is only exercised by
> the much-beaten fk-deadlock cases. If either of the steps fails with a
> deadlock error, it is reported identically, i.e. the error message is
> emitted as
> "error in s1u1 s2u1: ERROR: deadlock detected"
> So the deadlock could have been detected in either s1u1 or s2u1; we
> don't really care.
Hmm. For the case of "deadlock detected", we actually don't *want* to
care because the infrastructure is such that either process might report
it. So I agree that this is a good fix for that case. I'm just worried
whether it will obscure other situations where it's important to know
which command failed. But if you're convinced there aren't any, fine.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-09-27 22:18:17 | Re: contrib/sepgsql regression tests are a no-go |
Previous Message | Tom Lane | 2011-09-27 19:39:07 | Re: contrib/sepgsql regression tests are a no-go |