Re: FOR KEY LOCK foreign keys - Mailing list pgsql-hackers

From Noah Misch
Subject Re: FOR KEY LOCK foreign keys
Date
Msg-id 20110713053407.GA19443@tornado.leadboat.com
Whole thread Raw
In response to Re: FOR KEY LOCK foreign keys  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: FOR KEY LOCK foreign keys
List pgsql-hackers
On Tue, Jul 12, 2011 at 05:59:01PM -0400, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of vie mar 11 12:51:14 -0300 2011:
> > On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
> > > Automated tests would go a long way toward building confidence that this patch
> > > does the right thing.  Thanks to the SSI patch, we now have an in-tree test
> > > framework for testing interleaved transactions.  The only thing it needs to be
> > > suitable for this work is a way to handle blocked commands.  If you like, I can
> > > try to whip something up for that.
> > [off-list ACK followed]
> >
> > Here's a patch implementing that.  It applies to master, with or without your
> > KEY LOCK patch also applied, though the expected outputs reflect the
> > improvements from your patch.  I add three isolation test specs:
> >
> >   fk-contention: blocking-only test case from your blog post
> >   fk-deadlock: the deadlocking test case I used during patch review
> >   fk-deadlock2: Joel Jacobson's deadlocking test case
>
> Thanks for this patch.  I have applied it, adjusting the expected output
> of these tests to the HEAD code.  I'll adjust it when I commit the
> fklocks patch, I guess, but it seemed simpler to have it out of the way;
> besides it might end up benefitting other people who might be messing
> with the locking code.

Great.  There have been a few recent patches where I would have used this
functionality to provide tests, so I'm glad to have it in.

> > I think this will work on Windows as well as pgbench does, but I haven't
> > verified that.
>
> We will find out shortly.

I see you've added a fix for the MSVC animals; thanks.

coypu failed during the run of the test due to a different session being chosen
as the deadlock victim.  We can now vary deadlock_timeout to prevent this; see
attached fklocks-tests-deadlock_timeout.patch.  This also makes the tests much
faster on a default postgresql.conf.

crake failed when it reported waiting on the first step of an existing isolation
test ("two-ids.spec").  I will need to look into that further.

Thanks,
nm

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Blind attempt at fixing isolation_tester on Win32
Next
From: Ashutosh Bapat
Date:
Subject: Re: dropping table in testcase alter_table.sql