Thread: More on async-notify, smp-ppc

More on async-notify, smp-ppc

From
eric soroos
Date:
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
updateprocess. Processor time hasn't incremented in 2 minutes. The selects aren't progressing either.  Regular kills to
thepostgres processes don't do anything. Killing the client application doesn't kill the backends. It doesn't appear
thatprocesses 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



Re: More on async-notify, smp-ppc

From
Tom Lane
Date:
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
differentform.  

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

            regards, tom lane