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

From Robert Haas
Subject Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Date
Msg-id AANLkTilDiNU4Dy-_jTWgfrDxU1qg3ntFq_EBOuR9rcKm@mail.gmail.com
Whole thread Raw
In response to Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: patch: preload dictionary new version
Next
From: Magnus Hagander
Date:
Subject: Re: Keepalives win32