On Wed, Oct 22, 2014 at 2:14 AM, edward745 <cedward...@gmail.com> wrote: > One of the queries in ri_triggers.c has be a little baffled. > > For (relatively) obvious reasons, a FK insert triggers a SELECT 1 FROM > pk_rel ... FOR KEY SHARE. > For not-so-obvious reasons, a PK delete triggers a SELECT 1 FROM fk_rel ... > FOR KEY SHARE. > > I can't see what the lock on fk_rel achieves. Both operations are already > contending for the lock on the PK row, which seems like enough to cover > every eventuality. > > And even if the lock serves a purpose, KEY SHARE is an odd choice, since the > referencing field is, in general, not a "key" in this sense.
Please don't post unrelated questions onto existing mailing list threads. Start a new thread for a new topic. Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
