Re: curious regression failures

"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