From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:39:12 |
Message-ID: | 20131213163912.GN29402@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-12-13 11:26:44 -0500, Tom Lane wrote:
> 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.
Shouldn't the HOLD_INTERRUPTS() in handle_sig_alarm() prevent any
eventual ProcessInterrupts() in the timeout handlers from doing anything
harmful?
Even if so, making sure ImmediateInterruptOK is preserved seems worthwile
anyway.
> 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.
Yes, looks broken to me.
> I didn't find any other similar hazards in a quick look through all our
> signal handlers.
One thing I randomly noticed just now is the following in
RecoveryConflictInterrupt():
elog(FATAL, "unrecognized conflict mode: %d",
(int) reason);
obviously that's not really ever going to hit, but it should either be a
PANIC or an Assert() for the reasons you cite.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-12-13 16:39:20 | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
Previous Message | Tom Lane | 2013-12-13 16:26:44 | Re: "stuck spinlock" |