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.
> 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?
Hmm. I think Jim is right in that what we need is to make some forms of
ALTER TABLE take a lighter lock, one that doesn't conflict with analyze.
Guillaume's complaint are about restore times, which can only be
affected by analyze, not vacuum.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support