Horton

Re: First steps with 8.3 and autovacuum launcher

Alvaro Herrera <alvherre@commandprompt.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Matthew T. O'Connor" <matthew@zeut.net>, Simon Riggs <simon@2ndquadrant.com>, Heikki Linnakangas <heikki@enterprisedb.com>, Gregory Stark <stark@enterprisedb.com>, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, Guillaume Smet <guillaume.smet@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2007-10-02T14:58:22Z
Lists: pgsql-hackers 
Tom Lane escribió:
> I wrote:
> > Actually, if you wanted a low-hanging solution to that, it would
> > probably be to revert this 8.2 patch:
> > http://archives.postgresql.org/pgsql-committers/2006-09/msg00284.php
> 
> Uh ... never mind, that won't help at all.  Reducing the lock taken for
> ANALYZE could allow CREATE INDEX (ShareLock) to run concurrently.  But
> ALTER TABLE wants AccessExclusive lock, and no amount of fine-tuning of
> the conflicting lock will help.
> 
> It might be possible to solve this if we reduce the strength of the lock
> used for ALTER TABLE.  We'd have to go through all the commands
> potentially issued by a pg_dump script and see if they could all be made
> to run concurrently with autovac, which is a bit nervous-making but
> might be feasible; and I'm afraid tablecmds.c would need some
> restructuring to not use the same lock type for every variant of ALTER.
> But it seems like a path worth investigating.

Right.  Are you going to work on it, or do you want me to propose a
patch?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support