On Tue, Aug 14, 2012 at 5:46 PM, Tom Lane wrote:
> Noah Misch 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 wrote:
It is possible to check if the signal was synchronous or was sent from
an external process. You c
Noah Misch 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 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 sig
On Tue, Aug 14, 2012 at 08:40:06AM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark 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 check
Noah Misch 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 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 S
On Tue, Aug 14, 2012 at 8:55 AM, k...@rice.edu wrote:
> On Mon, Aug 13, 2012 at 11:52:06PM -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch wrote:
>> >> Overall, though, I think it best to plug this. We could set a flag before
>> >> each operation,
On Tue, Aug 14, 2012 at 08:38:44AM -0400, Robert Haas wrote:
> On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane 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 treated as a c
On Mon, Aug 13, 2012 at 11:52:06PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch 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
> >>
On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark 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 asynchrono
On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch 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.
>
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.
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,
Robert Haas writes:
> On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch 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 thought of, too. It seems like it'd
On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch 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 best to plug th
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 ha
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 cheerful
15 matches
Mail list logo
