| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, Christophe Pettus <xof(at)thebuild(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: "stuck spinlock" |
| Date: | 2013-12-13 16:26:44 |
| Message-ID: | 22510.1386952004@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On closer inspection, I'm thinking that actually it'd be a good idea if
handle_sig_alarm did what we do in, for example, HandleCatchupInterrupt:
it should save, clear, and restore ImmediateInterruptOK, so as to make
the world safe for timeout handlers to do things that might include a
CHECK_FOR_INTERRUPTS.
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.
I didn't find any other similar hazards in a quick look through all our
signal handlers.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-12-13 16:39:12 | Re: "stuck spinlock" |
| Previous Message | Andres Freund | 2013-12-13 15:37:24 | Re: "stuck spinlock" |