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.
-----
aaaaaaa
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Getting-rid-of-accept-incoming-network-connections-prompts-on-OS-X-tp5823819p5823890.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.