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
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 |