Skip site navigation (1) Skip section navigation (2)

Re: curious regression failures

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: curious regression failures
Date: 2007-09-21 01:26:50
Message-ID: 18147.1190338010@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-09-21 01:55:02
Subject: Re: HOT is applied
Previous:From: ஆமாச்சுDate: 2007-09-21 01:15:24
Subject: Beginning Tamil Community for Postgre

pgsql-patches by date

Next:From: Joshua D. DrakeDate: 2007-09-21 01:27:57
Subject: Re: [PATCHES] Patch to update log levels
Previous:From: Alvaro HerreraDate: 2007-09-21 01:20:19
Subject: Re: adjust chr()/ascii() to prevent invalidly encodeddata

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group