From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | rgr(at)cslab(dot)de, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8579: CoreDump of background writer process |
Date: | 2013-11-06 15:57:17 |
Message-ID: | 29013.1383753437@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> I wonder if the problem is mishandling of signals -- i.e. perhaps the
> port is at fault, or maybe it was right in 8.3 but we changed something
> that would affect the port, and it wasn't properly updated to match.
The postmaster log looked like the problem was triggered by SIGHUP
arriving while the bgwriter was doing an lseek(). It's not usual
for seeks to be interruptable, though, unless maybe you're running
the database over NFS? I tend to not trust that kind of arrangement
much, mainly because NFS exposes you to all sorts of poorly-tested
error recovery paths. Like this one.
Anyway, in theory the bgwriter ought to be able to recover from
such an error. Somehow the local state of BackgroundWriterMain
is getting messed up, though.
>> #0 0x00000000 in ?? ()
>> #1 0x08205ef4 in BackgroundWriterMain ()
>> #2 0x080e2759 in AuxiliaryProcessMain ()
> Not very useful, is it :-(
The OP did provide a stack trace with debug symbols, further down.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rene Grün | 2013-11-06 16:25:53 | Re: BUG #8579: CoreDump of background writer process |
Previous Message | Alvaro Herrera | 2013-11-06 15:44:31 | Re: BUG #8579: CoreDump of background writer process |