Re: referential Integrity and SHARE locks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: referential Integrity and SHARE locks
Date
Msg-id 9067.1170963218@sss.pgh.pa.us
Whole thread Raw
In response to Re: referential Integrity and SHARE locks  (Marc Munro <marc@bloodnok.com>)
Responses Re: referential Integrity and SHARE locks  (Marc Munro <marc@bloodnok.com>)
List pgsql-hackers
Marc Munro <marc@bloodnok.com> writes:
> Yes in this case, T1 must abort because the record it was going to
> update has disappeared from underneath it.  I don't see how this is
> significantly different from the same race for the record if the table
> had no RI constraints.  The only difference that I can see, is that T1
> now has some locks that it must relinquish as the transaction aborts.

No, the difference is there would have been no error at all before;
if the record were deleted before T1 got to it then it wouldn't have
attempted to update it.  I really don't think you can make it work
to perform updates or deletes on a record you have not yet locked.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: FreeBSD 6.2 ./configure plays oddly when building 8.2.2 from tarball
Next
From: "Andrew Hammond"
Date:
Subject: Re: FreeBSD 6.2 ./configure plays oddly when building 8.2.2 from tarball