Skip site navigation (1) Skip section navigation (2)

Re: Referential Integrity and SHARE locks

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Referential Integrity and SHARE locks
Date: 2007-02-02 18:35:05
Message-ID: 20070202102821.S73863@megazone.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

Responses

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group