Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Date: 2010-07-08 10:08:15
Message-ID: AANLkTilDiNU4Dy-_jTWgfrDxU1qg3ntFq_EBOuR9rcKm@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-07-08 10:20:14 pgsql: Add support for TCP keepalives on Windows, both for backend and
Previous Message Robert Haas 2010-07-08 09:53:13 Re: patch: preload dictionary new version