Re: "stuck spinlock"

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).

While I was developing the shared memory message queueing stuff, I
experimented using die() as the signal handler and didn't have very
good luck.  I can't remember exactly what wasn't working any more,
though.  I agree that it would be good if we can make that work.
Right now we've got other modules growing warts like
WalRcvImmediateInterruptOK, which doesn't seem good.

It seems to me that we should change every place that temporarily
changes ImmediateInterruptOK to restore the original value instead of
making assumptions about what it must have been.
ClientAuthentication(), md5_crypt_verify(), PGSemaphoreLock() and
WalSndLoop() all have this disease.

I also really wonder if notify and catchup interrupts ought to be
taught to respect ImmediateInterruptOK, instead of having their own
switches for the same thing.  Right now there are an awful lot of
places that do this:
               ImmediateInterruptOK = false;   /* not idle anymore */               DisableNotifyInterrupt();
   DisableCatchupInterrupt();
 

...and that doesn't seem like a good thing.  Heaven forfend someone
were to do only two out of the three.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company