On Sat, Dec 14, 2013 at 6:20 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-12-13 15:49:45 -0600, Merlin Moncure wrote:
>> On Fri, Dec 13, 2013 at 12:32 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> > On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >> And while we're on the subject ... isn't bgworker_die() utterly and
>> >> completely broken? That unconditional elog(FATAL) means that no process
>> >> using that handler can do anything remotely interesting, like say touch
>> >> shared memory.
>> >
>> > Yeah, but for the record (since I see I got cc'd here), that's not my
>> > fault. I moved it into bgworker.c, but it's been like that since
>> > Alvaro's original commit of the bgworker facility
>> > (da07a1e856511dca59cbb1357616e26baa64428e).
>>
>>
>> Is this an edge case or something that will hit a lot of users?
>> Arbitrary server panics seems pretty serious...
>
> Is your question about the bgworker part you're quoting or about the
> stuck spinlock stuff? I don't think the bgworker bug is too bad in
> practice but the one in handle_sig_alarm() stuff certainly is.
>
> I think while it looks possible to hit problems without statement/lock
> timeout, it's relatively unlikely that those are hit in practice.
Well, both -- I was just wondering out loud what the severity level of
this issue was. In particular, is it advisable for the general public
avoid this release? My read on this is 'probably'.
merlin