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

> 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                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to