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