Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Дата
Msg-id AANLkTilDiNU4Dy-_jTWgfrDxU1qg3ntFq_EBOuR9rcKm@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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.

Forgive me if I press on this just a bit further, but ISTM that an
atomic pg_class update functionality isn't intrinsically required,
because if it were the current code would need it.  So what is
changing in this patch that makes it necessary when it isn't now?
ISTM it must be that the lock is weaker.  What am I missing?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: patch: preload dictionary new version
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Keepalives win32