From: Gregory Stark <stark@enterprisedb.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: pgsql-hackers@postgresql.org
Subject: Re: curious regression failures
Date: Mon, 24 Sep 2007 10:07:20 +0100
Message-ID: <87zlzctos7.fsf@oxford.xeocode.com> (raw)
In-Reply-To: <20070924052821.GF5661@alvh.no-ip.org>
References: <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>
<18147.1190338010@sss.pgh.pa.us>
<20070924052821.GF5661@alvh.no-ip.org>
"Alvaro Herrera" <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>
>> 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.
>
> Hmm, right. We didn't change this in 8.3 but it looks like somebody
> will need to have a great idea before long.
>
> Of course, the easy answer is to grab a session-level lock for the main
> table while vacuuming the toast table, but it doesn't seem very
> friendly.
Just a normal lock would do, no? At least for normal (non-full) vacuum.
I'm not clear why this has to be dealt with at all though. What happens if we
don't do anything? Doesn't it just mean a user trying to drop the table will
block until the vacuum is done? Or does dropping not take a lock on the toast
table?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
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: stark@enterprisedb.com, alvherre@commandprompt.com, tgl@sss.pgh.pa.us, andrew@dunslane.net, stefan@kaltenbrunner.cc
Subject: Re: curious regression failures
In-Reply-To: <87zlzctos7.fsf@oxford.xeocode.com>
* 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