SIGFPE handler is naive

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: SIGFPE handler is naive
Date: 2012-08-13 17:04:58
Message-ID: CA+TgmoamzRWvu6pTkvhg2Qm02k86UUK2d4iQ+JVBwx9MxbfYkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

A member of our technical team brought it to my attention that if you
have a recalcitrant backend that doesn't die when you send it a
SIGTERM, and you don't want to cause a crash-and-restart cycle by
sending it SIGQUIT, you can have your cake and eat it too by sending
it SIGFPE, which will cheerfully throw an error from wherever inside
the backend you happen to be, whether it is safe or not. I suppose we
had it in mind when this was coded that SIGFPE would only be generated
by the system rather than by user activity, and it is a pretty neat
trick for working around the lack of CHECK_FOR_INTERRUPTS() in some
place where you really wish there were one, but the possibility of
setting yourself on fire also seems rather high. Since the person who
made the discovery realized the utility of the trick but not the fact
that it might destabilize the backend, it seems that the surface area
for self-destruction is non-zero.

Should we do something to plug this, and if so, what? If not, should
we document the danger?

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2012-08-13 19:35:58 Re: ALTER command reworks
Previous Message Pavel Stehule 2012-08-13 16:13:17 sharing variables between client and server again