From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: server crash with "process 22821 releasing ProcSignal slot 32, but it contains 0" |
Date: | 2012-06-26 17:09:22 |
Message-ID: | CAHyXU0zibvqO53wm-w1kw9oSK0KKN0faPoWwWr38W039HUGZ4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Jun 26, 2012 at 12:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> I suspect (but haven't had time to prove and may not for several days
>> -- unfortunately going on vacation momentarily) that this might be
>> caused by pl/sh.
>
> Hm. The reported symptoms might be explainable if something had caused
> multiple threads to become active within the backend process --- then
> it would be plausible for it to try to do proc_exit cleanup twice.
> Which would explain the first two errors, though I'm not sure how that
> leads to failing to disown the process latch, as the third error
> suggests must have happened. But I don't know enough about pl/sh to
> know if it could cause threading activation.
>
>> In particular, we have a routine that was
>> inadvertently applied to the database in with windows cr/lf instead of
>> the normal linux newline.
>
> This doesn't seem real promising as an explanation ...
right -- just a suspicion. maybe the relevant point was that it
immediately failed. operator invoking the busted routine (which I had
to fix) and the crash were highly correlated, although it does not
always crash. yesterday was very heavy load and today not so much.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Jimmy Creeks | 2012-06-26 20:31:41 | Re: BUG #6705: 32 bit |
Previous Message | Tom Lane | 2012-06-26 17:02:35 | Re: server crash with "process 22821 releasing ProcSignal slot 32, but it contains 0" |