Re: random isolation test failures

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:22:57
Message-ID: 1317149986-sup-664@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Excerpts from Tom Lane's message of mar sep 27 01:11:39 -0300 2011:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > I just tweaked isolationtester so that it collects the error messages
> > and displays them all together at the end of the test. After seeing it
> > run, I didn't like it -- I think I prefer something more local, so that
> > in the only case where we call try_complete_step twice in the loop, we
> > report any errors in either. AFAICS this would make both expected cases
> > behave identically in test output.
>
> 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.

The way error messages are reported in all the other cases is not
changed, and these do not have a prefix; so if anything were to behave
differently, we would find out because a spurious prefix would appear.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment Content-Type Size
isolation-fix-2.patch application/octet-stream 25.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-09-27 19:39:07 Re: contrib/sepgsql regression tests are a no-go
Previous Message Kevin Grittner 2011-09-27 18:42:26 Re: [PATCH] Addition of some trivial auto vacuum logging