On Tue, Aug 14, 2012 at 5:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Noah Misch n...@leadboat.com writes:
On Tue, Aug 14, 2012 at 08:40:06AM -0400, Robert Haas wrote:
On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark st...@mit.edu wrote:
It is possible to check if the signal was synchronous or was
Should we do something to plug this, and if so, what? If not, should
we document the danger?
I am not sure if I really understood the intention of the question correctly,
but if the question was if pg should try to work around misuse of signals, then
my answer would be a definite no.
IMHO,
It is possible to check if the signal was synchronous or was sent from
an external process. You can check siginfo-si_pid to see who sent you
the signal. I'm not sure checking that and handling it at
check_for_interrupts if it's asynchronous is the best solution or not
though.
I'm a bit confused.
On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch n...@leadboat.com wrote:
Overall, though, I think it best to plug this. We could set a flag before
each operation, like evaluation of SQL
On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark st...@mit.edu wrote:
It is possible to check if the signal was synchronous or was sent from
an external process. You can check siginfo-si_pid to see who sent you
the signal. I'm not sure checking that and handling it at
check_for_interrupts if it's
On Mon, Aug 13, 2012 at 11:52:06PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch n...@leadboat.com wrote:
Overall, though, I think it best to plug this. We could set a flag before
each operation, like evaluation of SQL
On Tue, Aug 14, 2012 at 08:38:44AM -0400, Robert Haas wrote:
On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That would depend on how many places there are where SIGFPE is expected.
Are we sure there are any? Maybe we should just remove the handler and
let SIGFPE be
On Tue, Aug 14, 2012 at 8:55 AM, k...@rice.edu k...@rice.edu wrote:
On Mon, Aug 13, 2012 at 11:52:06PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch n...@leadboat.com wrote:
Overall, though, I think it best to plug this. We
Noah Misch n...@leadboat.com writes:
On Tue, Aug 14, 2012 at 08:38:44AM -0400, Robert Haas wrote:
On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That would depend on how many places there are where SIGFPE is expected.
Are we sure there are any? Maybe we should just
On Tue, Aug 14, 2012 at 08:40:06AM -0400, Robert Haas wrote:
On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark st...@mit.edu wrote:
It is possible to check if the signal was synchronous or was sent from
an external process. You can check siginfo-si_pid to see who sent you
the signal. I'm not sure
Noah Misch n...@leadboat.com writes:
On Tue, Aug 14, 2012 at 08:40:06AM -0400, Robert Haas wrote:
On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark st...@mit.edu wrote:
It is possible to check if the signal was synchronous or was sent from
an external process. You can check siginfo-si_pid to see who
On Mon, Aug 13, 2012 at 01:04:58PM -0400, Robert Haas wrote:
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
On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch n...@leadboat.com wrote:
If this use of SIGFPE is handy, we should expose it under a better name. What
hazards make it unsafe?
Well, the most obvious problem is that a backend might receive it
while holding a spinlock.
Overall, though, I think it
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch n...@leadboat.com wrote:
Overall, though, I think it best to plug this. We could set a flag before
each operation, like evaluation of SQL arithmetic, for which SIGFPE is
normal.
Yeah, that's what I
14 matches
Mail list logo
