From: | Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> |
---|---|
To: | Herouth Maoz <herouth(at)unicell(dot)co(dot)il> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: What's canceling autovacuum tasks? |
Date: | 2011-02-06 22:47:29 |
Message-ID: | 13EA19F5-17D4-4444-818B-82487FF08FD0@solfertje.student.utwente.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 6 Feb 2011, at 18:52, Herouth Maoz wrote:
> on 06/02/11 18:16, quoting Tom Lane:
>>
>> Most likely, some other session requested an exclusive lock on the
>> table. Autovacuum will quit to avoid blocking the other query.
>>
> That's strange. During the day, only selects are running on that database, or at worst, temporary tables are being created and updated. And that particular table gets updated only on weekends (it's one of my archive tables). Besides, I assume that a simple update/insert/delete is not supposed to request an exclusive lock, or autovacuum would not work at all in an average database. Even backups don't run during the day, and I think backups also don't create an exclusive lock or I'd never see a vacuum process run more than a day.
>
> This is really inexplicable.
You could try turning on statement-level logging. On a busy database the logs would probably grow huge, but you should be able to see what statements coincide with autovacuum aborting.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d4f250611735773614733!
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Armel Luce | 2011-02-07 08:20:36 | Question about switchover with PG9 replication |
Previous Message | Francisco Figueiredo Jr. | 2011-02-06 21:39:43 | Re: "could not accept SSPI security context" |