Re: How about a option to disable autovacuum cancellation on lock conflict? - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: How about a option to disable autovacuum cancellation on lock conflict?
Date
Msg-id 547AA141.1010308@BlueTreble.com
Whole thread Raw
In response to How about a option to disable autovacuum cancellation on lock conflict?  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: How about a option to disable autovacuum cancellation on lock conflict?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 11/29/14, 2:22 AM, Andres Freund wrote:
> Hi,
>
> I've more than once seen that autovacuums on certain tables never
> succeed because regular exclusive (or similar) lockers cause it to give
> way/up before finishing.  Usually if some part of the application uses
> explicit exclusive locks.
>
> In general I think it's quite imortant that autovacuum bheaves that
> way. But I think it might be worhtwile to offer an option to disable
> that behaviour. If some piece of application logic requires exclusive
> locks and that leads to complete starvation of autovacuum, there's
> really nothing that can be done but to manually schedule vacuums right
> now.
>
> I can see two possible solutions:
>
> 1) Add a reloption that allows to configure whether autovacuum gives way
>     to locks acquired by user backends.
> 2) Add a second set of autovacuum_*_scale_factor variables that governs
>     a threshhold after which autovacuum doesn't get cancelled anymore.
>
> Opinions?

What do you mean by "never succeed"? Is it skipping a large number of pages? Might re-trying the locks within the same
vacuumhelp, or are the user locks too persistent?
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."
Next
From: Mart Kelder
Date:
Subject: Re: Removing INNER JOINs