From: | Marc Munro <marc(at)bloodnok(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: referential Integrity and SHARE locks |
Date: | 2007-02-08 19:46:04 |
Message-ID: | 1170963964.21038.59.camel@bloodnok.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2007-08-02 at 14:33 -0500, Tom Lane wrote:
> Marc Munro <marc(at)bloodnok(dot)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.
The record would be locked before the update or delete is attempted,
however it would not be locked until the referential integrity
constraints have succeeded in acquiring their locks.
It is becoming clear to me that I am missing something but I still don't
know what it is. If anyone can see it and explain it I'd really
appreciate it.
__
Marc
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-02-08 19:59:37 | Re: Proposal: Commit timestamp |
Previous Message | Bruce Momjian | 2007-02-08 19:38:36 | Re: Proposal: Commit timestamp |