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
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 |