Re: pqsignal - to be or (in this case) not to be

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: pqsignal - to be or (in this case) not to be
Date: 2004-02-04 23:34:08
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE34B13C@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

>"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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

Responses

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Tom Lane 2004-02-04 23:38:18 Re: pqsignal - to be or (in this case) not to be
Previous Message Tom Lane 2004-02-04 23:31:07 Re: pqsignal - to be or (in this case) not to be