Re: autovacuum not freeing up unused space on 8.3.0

>> >> ERROR: canceling autovacuum task
>> >> CONTEXT: automatic vacuum of table "metadb.test.transactions"
>> >
>> > Are these happening regularly? They indicate that something is
>> > happening on the table that collides with what autovacuum needs to do,
>> > and autovacuum defers its task. For this to happen you need to be doing
>> > ALTER TABLE or similar however; normal UPDATE/INSERT/DELETE should not
>> > cause autovacuum to cancel itself.
>> >
>> I am not using an ALTER table command but I am doing periodic ANALYZEs
>> to evaluate the table size. Could this be causing the problem? I notice
>> that stopping the ANALYZE calls appears to eliminate the canceled
>> autovacuum.
>>
>
>
> I am trying to reproduce the case here, but could not. Can you post the table
> schema and the operations you are carrying out ? Is it just INSERT new rows
> and DELETE old rows or are there any UPDATEs too ? Are there any long
> running transactions open ?
>

It'll take a few minutes but I'll try and get the information to you. A
summary is:

Process 1:
- writing 50 rows/second, 1 row/transaction.
- every so often delete 100 rows

Process 2:
- running ANALYZE VERBOSE and pg_total_relation_size every second

The result is that autovacuum appears to be canceled.

I was incorrect about autovacuum not recovering. Once I stop the
ANALYZEs it appears to stabilise and recover some of the space after a
little while. At that point a VACUUM FULL does help, and recovers quite
a bit of space. I'll run through this again here and provide you with
logs and VACUUM printouts.

>> What concerns me is that once the size has grown, even a VACUUM FULL
>> doesn't recover the space. Regular external VACUUMs keep the table at
>> around 10MB but if I use autovacuum and it grows to 40MB, a VACUUM FULL
>> will only get it down to 35MB. Is it possible that a canceled autovacuum
>> could result in permanently lost space?
>>
>
> AFAIK it should not. Can you also post VACUUM FULL VERBOSE output ?

Thanks for your help,
Stuart