Oops, forgot to include pgsql-hackers when I responded to this the first time.
On Tue, 2007-06-02 at 20:53 -0500, Tom Lane wrote: > Marc Munro <[EMAIL PROTECTED]> writes: > > The RI triggers currently fire when a record is updated. Under my > > proposal they would fire in the same way but before the record is locked > > rather than after. Or am I missing your point? > > IOW, some other transaction could update or delete the tuple meanwhile? > Doesn't seem very promising. > That other transaction, T1, would have run the same RI triggers and so would have the same parent records locked. The blocked transaction, T2, once T1 has committed, would fail. I don't see this as being much different from the current case, where T1 locks and deletes or updates a row, and T2 then tries to manipulate the same row. In both cases, locks manage the race for the row, and MVCC ensures that T2 fails. __ Marc
signature.asc
Description: This is a digitally signed message part
