On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote: > Rereading the thread, I'm a bit confused by why we're proposing to use > a SHARE lock; it seems to me that a self-conflicting lock type would > simplify things. There's a bunch of discussion on the thread about > how to handle pg_class updates atomically, but doesn't using a > self-conflicting lock type eliminate that problem?
The use of the SHARE lock had nothing to do with the pg_class update requirement, so that suggestion won't help there. > It strikes me that for the following operations, which don't affect > queries at all, we could use a SHARE UPDATE EXCLUSIVE, which is likely > superior to SHARE for this purpose because it wouldn't lock out > concurrent DML write operations: Yes, we can also use SHARE UPDATE EXCLUSIVE for some of them. The use of SHARE lock was specifically targeted at ADD FOREIGN KEY, to allow multiple concurrent FKs. Not much use for production however, so SUE looks better to me. Not sure I agree with the "don't affect queries at all" bit.... I'll take my previous patch through to completion now, I'm funded to do that work now. Sept commitfest though. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
