More on async-notify, smp-ppc

Started by Eric Soroosabout 23 years ago2 messagesgeneral
Jump to latest
#1Eric Soroos
eric-psql@soroos.net

The deadlocks that I though were solved by the patch to async.c appear to be continuing, albeit in a somewhat different form.

This is an excerpt from ps ax | grep post
..
27200 ?? S 0:00.21 postgres: nobody nobody [local] async_notify
27245 ?? S 0:00.50 postgres: nobody nobody [local] async_notify
27249 ?? S 0:00.12 postgres: wiredfool wiredfoolcom [local] idle
27250 ?? S 0:00.11 postgres: wiredfool wiredfoolcom [local] async_notify
27967 ?? S 0:00.00 /usr/local/bin/psql -c VACUUM ANALYZE -d snet
27968 ?? S 0:36.50 postgres: erics snet [local] VACUUM
28012 ?? S 0:00.05 postgres: nobody snet [local] SELECT
28021 ?? S 0:02.53 postgres: nobody snet [local] SELECT
28080 ?? S 0:00.22 postgres: nobody nobody [local] idle
28101 ?? S 0:00.05 postgres: nobody nobody [local] INSERT
28102 ?? S 0:00.12 postgres: nobody nobody [local] idle
28267 ?? S 0:00.37 postgres: nobody snet [local] UPDATE
..

Activity to some databases appears not to be impaired, but the vacuum appears to have deadlocked snet, probably the update process. Processor time hasn't incremented in 2 minutes. The selects aren't progressing either. Regular kills to the postgres processes don't do anything. Killing the client application doesn't kill the backends. It doesn't appear that processes listed with async-notify show up in the listing in pg_stat_activity table.

This is on OSX, 10.1.5, Dual g4, postgres 7.2.4 + async.c patch.

Any more ideas?

eric

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Eric Soroos (#1)
Re: More on async-notify, smp-ppc

eric soroos <eric-psql@soroos.net> writes:

The deadlocks that I though were solved by the patch to async.c appear to be continuing, albeit in a somewhat different form.

Hm ... can you attach to the stuck processes with gdb and get stack
traces?

regards, tom lane