Re: allowing VACUUM to be cancelled for conflicting locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowing VACUUM to be cancelled for conflicting locks
Date: 2014-04-28 17:58:10
Message-ID: 23358.1398707890@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
> On Mon, Apr 28, 2014 at 12:52 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> Tom Lane wrote:
>>> Abhijit Menon-Sen <ams(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2014-04-28 18:00:27 Re: allowing VACUUM to be cancelled for conflicting locks
Previous Message Andres Freund 2014-04-28 17:51:06 Re: allowing VACUUM to be cancelled for conflicting locks