Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Date: 2010-02-22 15:32:17
Message-ID: 201002221532.o1MFWHi23562@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
> > Simon Riggs wrote:
> > >
> > > On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
> > > > Tom Lane wrote:
> > > > > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > > > > Is there a good reason for $subject, other than that the code is entangled
> > > > > > with other ALTER TABLE code?
> > > > >
> > > > > I think it could be lower, but it would take nontrivial restructuring of
> > > > > the ALTER TABLE support. In particular, consider what happens when you
> > > > > have a list of subcommands that don't all require the same lock level.
> > > > > I think you'd need to scan the list and find the highest required lock
> > > > > level before starting ...
> > > >
> > > > IIRC there was a patch from Simon to address this issue, but it had some
> > > > holes which he didn't have time to close, so it sank. Maybe this can be
> > > > resurrected and fixed.
> > >
> > > I was intending to finish that patch in this release cycle.
> >
> > Since you're busy with Hot Standby, any chance you could pass it on?
>
> If you'd like. It's mostly finished, just one last thing to finish:
> atomic changes to pg_class via an already agreed API.

I assume this did not get done for 9.0. Do we want a TODO item?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-22 15:42:08 Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Previous Message Pavel Stehule 2010-02-22 15:31:45 Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries