"Alvaro Herrera" <alvherre@commandprompt.com> 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
>> 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.
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
table?
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
