| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | imad | 2007-02-02 18:40:05 | Re: PL/pgSQL RENAME functionality in TODOs |
| Previous Message | Ioseph Kim | 2007-02-02 18:33:19 | problem of geometric operator in v8.2.1 |