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