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