Обсуждение: Unresponsive vacuum process

I have a 7.2.1 backend running VACUUM which appears to be blocking all other
processes.  I have issued SIGTERM and SIGINT directly to that backend and
also killed the client process, but the VACUUM continues chewing up CPU and
blocking others.  I know we need an upgrade; does anyone know how I can get
this VACUUM backend killed without taking down all the blocked/pending
UPDATEs and INSERTs?

"Ed L." <pgsql@bluepolka.net> writes:
> I have a 7.2.1 backend running VACUUM which appears to be blocking all other
> processes.  I have issued SIGTERM and SIGINT directly to that backend and
> also killed the client process, but the VACUUM continues chewing up CPU and
> blocking others.

Hmph.  AFAICS 7.2 does contain CHECK_FOR_INTERRUPT calls within all the
major VACUUM loops, so it should respond to SIGINT in a reasonably
timely fashion.  I'd think it was blocked on someone else's lock if it
weren't that you say it's still consuming CPU.  Can you attach to the
troublesome backend with gdb and get a stack trace to show where it is?

            regards, tom lane

On Wednesday May 19 2004 5:49, Tom Lane wrote:
> "Ed L." <pgsql@bluepolka.net> writes:
> > I have a 7.2.1 backend running VACUUM which appears to be blocking all
> > other processes.  I have issued SIGTERM and SIGINT directly to that
> > backend and also killed the client process, but the VACUUM continues
> > chewing up CPU and blocking others.
>
> Hmph.  AFAICS 7.2 does contain CHECK_FOR_INTERRUPT calls within all the
> major VACUUM loops, so it should respond to SIGINT in a reasonably
> timely fashion.  I'd think it was blocked on someone else's lock if it
> weren't that you say it's still consuming CPU.  Can you attach to the
> troublesome backend with gdb and get a stack trace to show where it is?

Had to kill it, couldn't wait.  Looks like we'll punt this one and just
upgrade the cluster, but if not, I'll try to capture.  Thanks.

On 5/19/04 6:49 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

>> I have a 7.2.1 backend running VACUUM which appears to be blocking all other
>> processes.  I have issued SIGTERM and SIGINT directly to that backend and
>> also killed the client process, but the VACUUM continues chewing up CPU and
>> blocking others.
>
> Hmph.  AFAICS 7.2 does contain CHECK_FOR_INTERRUPT calls within all the
> major VACUUM loops, so it should respond to SIGINT in a reasonably
> timely fashion.  I'd think it was blocked on someone else's lock if it
> weren't that you say it's still consuming CPU.  Can you attach to the
> troublesome backend with gdb and get a stack trace to show where it is?

I've had 7.4.1 take up to an hour and a half to abort a vacuum after a
SIGNIT.

Wes

<wespvp@syntegra.com> writes:
> On 5/19/04 6:49 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> ...  I'd think it was blocked on someone else's lock if it
>> weren't that you say it's still consuming CPU.  Can you attach to the
>> troublesome backend with gdb and get a stack trace to show where it is?

> I've had 7.4.1 take up to an hour and a half to abort a vacuum after a
> SIGNIT.

The request for information still stands.  I can't do a thing with
undetailed anecdotes.

            regards, tom lane