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