From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Gregory Stark <stark@enterprisedb.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: pgsql-hackers@postgresql.org
Subject: Re: curious regression failures
Date: Thu, 20 Sep 2007 21:26:50 -0400
Message-ID: <18147.1190338010@sss.pgh.pa.us> (raw)
In-Reply-To: <20070921011321.GO30013@alvh.no-ip.org>
References: <46EADA0A.3040504@kaltenbrunner.cc>
<12435.1189821208@sss.pgh.pa.us>
<46EC07E7.9000100@kaltenbrunner.cc>
<28630.1189875785@sss.pgh.pa.us>
<46ED527A.4090108@kaltenbrunner.cc>
<20616.1190214860@sss.pgh.pa.us>
<46F1468F.1080903@dunslane.net>
<22220.1190219640@sss.pgh.pa.us>
<87r6kuh426.fsf@oxford.xeocode.com>
<26362.1190236564@sss.pgh.pa.us>
<20070921011321.GO30013@alvh.no-ip.org>
Alvaro Herrera <alvherre@commandprompt.com> writes:
> In any case, at that point we are mostly done with the expensive steps
> of vacuuming, so the transaction finishes not long after this. I don't
> think this issue is worth inventing a new invalidation mechanism.
Yeah, I agree --- there are only a few catalog updates left to do after
we truncate. If we held the main-table exclusive lock while vacuuming
the TOAST table, we'd have a problem, but it looks to me like we don't.
Idle thought here: did anything get done with the idea of decoupling
main-table vacuum decisions from toast-table vacuum decisions? vacuum.c
comments
* Get a session-level lock too. This will protect our access to the
* relation across multiple transactions, so that we can vacuum the
* relation's TOAST table (if any) secure in the knowledge that no one is
* deleting the parent relation.
and it suddenly occurs to me that we'd need some other way to deal with
that scenario if autovac tries to vacuum toast tables independently.
Also, did you see the thread complaining that autovacuums block CREATE
INDEX? This seems true given the current locking definitions, and it's
a bit annoying. Is it worth inventing a new table lock type just for
vacuum?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@commandprompt.com, stark@enterprisedb.com, andrew@dunslane.net, stefan@kaltenbrunner.cc
Subject: Re: curious regression failures
In-Reply-To: <18147.1190338010@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox