"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> 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
>> * 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
Just a normal lock would do, no? At least for normal (non-full) vacuum.
I'm not clear why this has to be dealt with at all though. What happens if we
don't do anything? Doesn't it just mean a user trying to drop the table will
block until the vacuum is done? Or does dropping not take a lock on the toast
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings