ROW SHARE/SELECT ... FOR UPDATE + foreign keys

Started by Thomas F.O'Connellalmost 21 years ago2 messagesdocs
Jump to latest
#1Thomas F.O'Connell
tfo@sitening.com

What would people think of adding a note to the ROW SHARE section of
Table-Level Locks remarking on the fact that referential integrity
checks expressed through foreign keys do SELECT ... FOR UPDATES.

http://www.postgresql.org/docs/8.0/static/explicit-
locking.html#LOCKING-TABLES

It was somewhat challenging today to try to track down a pervasive
locking issue related to a table not directly referenced in a stored
procedure but that was referenced by a key in a table that was being
updated.

I'm not sure how this changes with the new shared row locking
implementation in 8.1...

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

#2Bruce Momjian
bruce@momjian.us
In reply to: Thomas F.O'Connell (#1)
Re: ROW SHARE/SELECT ... FOR UPDATE + foreign keys

Thomas F. O'Connell wrote:

What would people think of adding a note to the ROW SHARE section of
Table-Level Locks remarking on the fact that referential integrity
checks expressed through foreign keys do SELECT ... FOR UPDATES.

http://www.postgresql.org/docs/8.0/static/explicit-
locking.html#LOCKING-TABLES

It was somewhat challenging today to try to track down a pervasive
locking issue related to a table not directly referenced in a stored
procedure but that was referenced by a key in a table that was being
updated.

I'm not sure how this changes with the new shared row locking
implementation in 8.1...

8.1 will use _shared_ row locks for such cases.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073