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

From Stephan Szabo
Subject Re: referential Integrity and SHARE locks
Date
Msg-id 20070208100037.N12047@megazone.bigpanda.com
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
On Thu, 8 Feb 2007, Marc Munro wrote:

> 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 <marc@bloodnok.com> 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.

That's not true in the case of delete, since the referencing table
triggers are on insert and update. Second, the parent record locks are not
exclusive which means that both can be granted, so I don't see how this
stops the second from continuing before the first.



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Chatter on DROP SOMETHING IF EXISTS
Next
From: "Andrew Hammond"
Date:
Subject: Re: BuildFarm: Do we need another FreeBSD/amd64 member?