Re: pqsignal - to be or (in this case) not to be - Mailing list pgsql-hackers-win32

From Magnus Hagander
Subject Re: pqsignal - to be or (in this case) not to be
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE34B13C@algol.sollentuna.se
Whole thread Raw
In response to pqsignal - to be or (in this case) not to be  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: pqsignal - to be or (in this case) not to be  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers-win32
>"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
>> As for the polling, adding a poll to one or two strategic plaes (like
>> the I/O subsystem) should cover 99% of the reasonable cases...
>
>Put it into the macro that checks for query cancel.

That sounds like a very good idea :-)

Are there other places that you know offhand that we should check for
signals? Consider other signals like TERM etc as well. Or is that macro
pretty much used at the points where we want signals delivered during
execution?


//Magnus

pgsql-hackers-win32 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pqsignal - to be or (in this case) not to be
Next
From: Tom Lane
Date:
Subject: Re: pqsignal - to be or (in this case) not to be