Re: "stuck spinlock"

Robert Haas escribió:
> On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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).

I see the blame falls on me ;-) I reckon I blindly copied this
stuff from elsewhere without thinking very much about it. As noted
upthread, even the example code uses a different handler for SIGTERM.
There wasn't much else that we could do; simply letting the generic code
run without any SIGTERM installed didn't seem the right thing to do.
(You probably recall that the business of starting workers with signals
blocked was installed later.)

I found a few workers in github in a quick search:
https://github.com/umitanuki/mongres/blob/master/mongres.c
https://github.com/markwkm/pg_httpd/blob/master/pg_httpd.c
https://github.com/ibarwick/config_log/blob/master/config_log.c
https://github.com/gleu/stats_recorder/blob/master/stats_recorder_spi.c
https://github.com/michaelpq/pg_workers/blob/master/kill_idle/kill_idle.c
https://github.com/le0pard/pg_web/blob/master/src/pg_web.c

Not a single one of the uses bgworker_die() -- they all follow
worker_spi's lead of setting a got_sigterm flag and SetLatch().

If there was a way for raising an #error at compile time whenever a
worker relies on the existing signal handler, I would vote for doing
that. (But then I have no idea how to do such a thing.)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services