Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndQuadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Cédric Villemain <cedric.villemain.debian@gmail.com>, Bruce Momjian <bruce@momjian.us>, Peter Eisentraut <peter_e@gmx.net>, Alvaro Herrera <alvherre@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2010-07-08T21:09:58Z
Lists: pgsql-hackers
On Thu, 2010-07-08 at 06:08 -0400, Robert Haas wrote:
> 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?

Not sure I follow that logic. Discussion on the requirement is in the
archives. I don't wish to question that aspect myself.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Development, 24x7 Support, Training and Services