Re: "stuck spinlock"

On 2013-12-13 12:54:09 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > I wonder what to do about bgworker's bgworker_die()? I don't really see
> > how that can be fixed without breaking the API?
>
> IMO it should be flushed and bgworkers should use the same die() handler
> as every other backend, or else one like the one in worker_spi, which just
> sets a flag for testing later.

Agreed on not going forward like now, but I don't really see how they
could usefully use die(). I think we should just mandate that every
bgworker conneced to shared memory registers a sigterm handler - we
could put a check into BackgroundWorkerUnblockSignals(). We should leave
the current handler in for unconnected one though...
bgworkers are supposed to be written as a loop around procLatch, so
adding a !got_sigterm, probably isn't too hard.

It sucks that people might have bgworkers out there that don't register
their own sigterm handlers, but adding a sigterm handler will be
backward compatible and it's in the example bgworker, so it's probably
not too bad.

> If we try to change the signal handling
> contracts, 80% of backend code will be unusable in bgworkers, which is not
> where we want to be I think.

Yea, I think that's out of the question.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services