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