Skip site navigation (1) Skip section navigation (2)

Re: BUG #4945: Parallel update(s) gone wild

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Dan Boeriu <dan(dot)boeriu(at)roost(dot)com>
Cc: PostgreSQL bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #4945: Parallel update(s) gone wild
Date: 2009-07-29 02:55:21
Message-ID: 4A6FBA19.1050809@postnewspapers.com.au (view raw or flat)
Thread:
Lists: pgsql-bugs
Dan Boeriu wrote:

> The second will not finish in 24h but the CPU stays at 100% and iostat 
> shows no IO other than the checkpoints.
 > IF I cancel the second UPDATE (pg_cancel_backend) and restart it (new
 > pgsql invocation) ASAP it goes through in 20 secs.

OK, that's interesting when combined with the information provided. 
(Though, in general, it's preferable that you quote command output as 
well as your interpretation; I think we all miss things sometimes.)

You might want to connect to the problem process (the one pegged at 100% 
CPU) with gdb and see if you can get a backtrace showing what's going on.

Where the pid of the problem process is shown as 9999 here:

gdb -p 9999
(gdb) bt
(gdb) cont
^C
(gdb) bt
(gdb) cont
^C
(gdb) bt
(gdb) cont
^C
(gdb) bt
(gdb) q
y


In other words: connect to the process with gdb. Issue the "bt" command 
(backtrace) to get a backtrace at the point you interrupted it at by 
connecting with gdb, then tell it to continue execution normally. After 
a little while (a few seconds/minutes/whatever, just tell us vaguely how 
long) hit control-C, request another backtrace, and tell the program to 
continue. Repeat a few times, then quit gdb and tell it to detach from 
the process.

Then send the ENTIRE, EXACT output to the mailing list.

If the output mostly looks like this:

#0  0xb7f6a410 in ?? ()
#1  0xbfe75578 in ?? ()
#2  0x00000000 in ?? ()

then your Linux distro has stripped debug info out of the Pg binaries. 
You may need to install debuginfo RPMs for PostgreSQL and glibc at the 
very least, then repeat the process of collecting backtrace information.

--
Craig Ringer

In response to

pgsql-bugs by date

Next:From: Jeff JanesDate: 2009-07-29 03:23:23
Subject: BUG #4952: commit_delay ignored because CountActiveBackends always returns zero
Previous:From: Robert HaasDate: 2009-07-29 02:05:04
Subject: Re: BUG #4949: NOT IN is prohibitive slower than the rewrite for medium to large sets

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group