Thread

  1. Re: FOR KEY LOCK foreign keys

    Noah Misch <noah@2ndquadrant.com> — 2011-07-13T05:34:10Z

    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