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 <alvhe...@alvh.no-ip.org> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers