Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Дата
Msg-id 1278569765.2446.29.camel@ebony
обсуждение исходный текст
Ответ на Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock  (Robert Haas <robertmhaas@gmail.com>)
Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: bitmap indexes - performance
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: keepalive in libpq using