Re: First steps with 8.3 and autovacuum launcher

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: First steps with 8.3 and autovacuum launcher
Date: 2007-10-02 14:55:00
Message-ID: 14375.1191336900@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-10-02 14:58:22 Re: First steps with 8.3 and autovacuum launcher
Previous Message Michael Meskes 2007-10-02 14:11:20 Re: pgsql: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> added