Обсуждение: Weird PostgreSQL crashes on FC2/FC3 64-bit

Since I've upgraded my development server to FC2/FC3 64-bit, I
occasionally get these weird PostgreSQL semi-lockups. Once in a while, a
query (usually a big update of some type) will just stop dead. Doing a
ps -ef | grep postgres, I will see something like:

root     17034     1  0 21:41 ?        00:00:00 gdb -q -x /dev/stdin
postgres 9131
postgres  9131  2712  0 20:31 ?        00:00:00 postgres: postgres
netdata [local] VACUUM

Other connections continue to run (unless the dead process causes a
pileup behind it) and I can make new connections to the DB.

The strange thing is I cannot kill the dead process. I can type "kill -9
9131" all day long (yes I know it's bad) but the process will not go
away. Doing kill -9 on all the other postmasters will make them go away
but the bad one will still stay forever. The gdb process is killable though.

At this point, this dead process is still on my machine. Are there any
commands for me to figure out what's going on here?

William Yu <wyu@talisys.com> writes:
> Doing a ps -ef | grep postgres, I will see something like:

> root     17034     1  0 21:41 ?        00:00:00 gdb -q -x /dev/stdin
> postgres 9131
> postgres  9131  2712  0 20:31 ?        00:00:00 postgres: postgres
> netdata [local] VACUUM

So where did the gdb come from?

> The strange thing is I cannot kill the dead process.

It's not dead --- gdb has got it by the throat.

            regards, tom lane

Tom Lane wrote:
> William Yu <wyu@talisys.com> writes:
>
>>Doing a ps -ef | grep postgres, I will see something like:
>
>
>>root     17034     1  0 21:41 ?        00:00:00 gdb -q -x /dev/stdin postgres 9131
>>postgres  9131  2712  0 20:31 ?        00:00:00 postgres: postgres netdata [local] VACUUM
>
>
> So where did the gdb come from?

To be honest, I do not know. I see the parent process is 1 so something
in the FCx kernel is triggering it. I just don't know where the logs for
something like this would be.


>>The strange thing is I cannot kill the dead process.
>
>
> It's not dead --- gdb has got it by the throat.

On Tue, Feb 01, 2005 at 10:32:15PM -0800, William Yu wrote:
> Tom Lane wrote:
> >William Yu <wyu@talisys.com> writes:
> >
> >>Doing a ps -ef | grep postgres, I will see something like:
> >
> >
> >>root     17034     1  0 21:41 ?        00:00:00 gdb -q -x /dev/stdin
> >>postgres 9131
> >>postgres  9131  2712  0 20:31 ?        00:00:00 postgres: postgres
> >>netdata [local] VACUUM
> >
> >
> >So where did the gdb come from?
>
> To be honest, I do not know. I see the parent process is 1 so something
> in the FCx kernel is triggering it. I just don't know where the logs for
> something like this would be.

Parent process 1 just means that it's either spawned by init or it's
real parent process has died. I wouldn't put any stock in it. Try using
"ps aux" to get the process state. Chances are it's in T (trace) state.
You can try to kill -CONT it. Maybe strace it.
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.