On Fri, 2007-02-02 at 10:35 -0800, Stephan Szabo wrote: > 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.
Probably best to read the later posts; this one was at the beginning of my thought train, so is slightly off track, as later posters remind me. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
