On 2013-12-13 15:49:45 -0600, Merlin Moncure wrote: > On Fri, Dec 13, 2013 at 12:32 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane <t...@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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
