Re: allowing VACUUM to be cancelled for conflicting locks

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowing VACUUM to be cancelled for conflicting locks
Date: 2014-04-28 18:00:27
Message-ID: CAMkU=1yb1zp7bY5TUbnyOHN4EyENnG0feY5hJN1mDStkWxGV4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 28, 2014 at 6:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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".
>

Autovac is also going to promote itself to uninterruptible once every 150e6
transactions (by the default settings).

To stop using manual vacuums is not going to be a complete cure anyway.

It would be nice to know why the scripts are doing the manual vacuum. Just
out of mythology, or is there an identifiable reason?

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-28 18:01:35 Re: allowing VACUUM to be cancelled for conflicting locks
Previous Message Tom Lane 2014-04-28 17:58:10 Re: allowing VACUUM to be cancelled for conflicting locks