Re: How about a option to disable autovacuum cancellation on lock conflict?

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How about a option to disable autovacuum cancellation on lock conflict?
Date: 2014-11-30 04:46:57
Message-ID: 547AA141.1010308@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 vacuum help, or are the user locks too persistent?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mart Kelder 2014-11-30 10:19:28 Re: Removing INNER JOINs
Previous Message Tom Lane 2014-11-30 03:12:41 Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."