On Fri, 2 Feb 2007, Simon Riggs wrote:

> It sounds like if we don't put a SHARE lock on the referenced table then
> we can end the transaction in an inconsistent state if the referenced
> table has concurrent UPDATEs or DELETEs. BUT those operations do impose
> locking rules back onto the referencing tables that would not be granted
> until after any changes to the referencing table complete, whereupon
> they would restrict or cascade. So an inconsistent state doesn't seem
> possible to me.

What locking back to the referencing table are you thinking about? The row
locks are insufficient because that doesn't prevent an insert of a
new row that matches the criteria previously locked against AFAIK.

In response to

• Referential Integrity and SHARE locks at 2007-02-02 09:51:36 from Simon Riggs

Responses

• Re: Referential Integrity and SHARE locks at 2007-02-02 20:19:44 from Simon Riggs

pgsql-hackers by date

Next:	From: imad	Date: 2007-02-02 18:40:05
	Subject: Re: PL/pgSQL RENAME functionality in TODOs
Previous:	From: Ioseph Kim	Date: 2007-02-02 18:33:19
	Subject: problem of geometric operator in v8.2.1