Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Date
Msg-id 1278569765.2446.29.camel@ebony
Whole thread Raw
In response to Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: bitmap indexes - performance
Next
From: Fujii Masao
Date:
Subject: Re: keepalive in libpq using