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
* 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
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 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. Drake||Date: 2007-09-21 01:27:57|
|Subject: Re: [PATCHES] Patch to update log levels|
|Previous:||From: Alvaro Herrera||Date: 2007-09-21 01:20:19|
|Subject: Re: adjust chr()/ascii() to prevent invalidly encodeddata|