improving foreign key locks

Hi,

So I've been working on improving locks for foreign key checks, as
discussed in a thread started by Joel Jacobson a while ago. I've posted
about this:
http://www.commandprompt.com/blogs/alvaro_herrera/2010/11/fixing_foreign_key_deadlocks/
http://www.commandprompt.com/blogs/alvaro_herrera/2010/11/fixing_foreign_key_deadlocks_part_2/
(Note [1] below).

There's a question that arose in internal CMD discussion, which is: is
there an use case for keeping SELECT FOR SHARE locks, with the semantics
that they currently have, if we replace the FK checks with some other
lock implementation?

I've been assuming that we would keep FOR SHARE, because it's a feature
that's been exposed to users directly as a SQL command for five
releases, and so presumably someone may be depending on it. So the new
code would be triggered by a different SQL option, and it needs to work
in conjunction with FOR SHARE.

Now, if the majority opinion here is that we don't need to keep the
current FOR SHARE semantics, a few things would be different.

Thoughts on keeping vs. removing FOR SHARE?

I will be posting more extensively on the implementation of this on this
list, later.

[1] The blog posts says that FOR SHARE would conflict with FOR KEY LOCK,
but I'm having second thoughts about this for various reasons; so they
will not conflict (in other words, transaction A can take a FOR SHARE
lock in a tuple, and transaction B can take FOR KEY LOCK, and they both
can continue). Please consider this if you want to comment on the
design presented in those articles.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>