Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

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