Re: allowing VACUUM to be cancelled for conflicting locks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: allowing VACUUM to be cancelled for conflicting locks
Date
Msg-id 23358.1398707890@sss.pgh.pa.us
Whole thread Raw
In response to Re: allowing VACUUM to be cancelled for conflicting locks  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: allowing VACUUM to be cancelled for conflicting locks  (Andres Freund <andres@2ndquadrant.com>)
Re: allowing VACUUM to be cancelled for conflicting locks  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Claudio Freire <klaussfreire@gmail.com> writes:
> On Mon, Apr 28, 2014 at 12:52 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> Tom Lane wrote:
>>> Abhijit Menon-Sen <ams@2ndquadrant.com> writes:
>>>> In the past, we've had situations where "everything is hung" turned out
>>>> to be because of a script that ran manual VACUUM that was holding some
>>>> lock. It's admittedly not a huge problem, but it might be useful if a
>>>> manual VACUUM could be cancelled the way autovacuum can be.

>>> I think the real answer to that is "stop using manual VACUUM".

>> As much as I'm a fan of autovacuum, that's not always possible.

> Or even recommended, unless the docs changed radically in the last
> couple of weeks.

Actually, having just looked at the code in question, I think this whole
thread is based on an obsolete assumption.  AFAICS, since commit b19e4250b
manual vacuum behaves exactly like autovacuum as far as getting kicked off
the exclusive lock is concerned.  There's certainly not any tests for
autovacuum in lazy_truncate_heap() today.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: allowing VACUUM to be cancelled for conflicting locks
Next
From: Jeff Janes
Date:
Subject: Re: allowing VACUUM to be cancelled for conflicting locks