From: | "Peter Koczan" <pjkoczan(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: trouble restarting a server |
Date: | 2007-05-22 21:05:30 |
Message-ID: | 4544e0330705221405w5c5a5eb2n5df936e7987cae97@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
The release is 8.2.4. I haven't been able to reproduce the condition yet,
but I will send along stack traces as soon as I can. I have this strange
feeling that it's only going to happen when I find a reason to make a
restart-worthy config change.
Peter
On 5/21/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Peter Koczan" <pjkoczan(at)gmail(dot)com> writes:
> > [ lots of processes stuck in "notify interrupt" code ]
>
> That's weird. If it's still in that state, or if you can reproduce it,
> could you attach to a few of those processes with gdb and get stack
> traces?
>
> Looking at the async.c code, an obvious candidate is that that routine
> tries to take ExclusiveLock on pg_listener --- so if something had
> managed to exit without releasing a lock on that table, hangups could be
> expected. But if that were the case, you'd think the process status
> lines would include "waiting". My guess is they're blocked on something
> lower-level than a table lock, but without a stack trace it's hard to
> guess what.
>
> Which PG release is this exactly?
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2007-05-22 23:18:18 | Re: Can I restrict backups? |
Previous Message | Alvaro Herrera | 2007-05-22 19:30:10 | Re: What happens on a commit? |