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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
