| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
| Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org, "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
| Subject: | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
| Date: | 2005-10-22 15:12:20 |
| Message-ID: | 1287.1129993940@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> I can unfortunatly conform that I'm also seeing this :-( I'm seeing it
> in some kind of tight loop in the plpgsql regression test. Either that,
> or it's just doing something *really* slowly. Doing some poking at it
> with procexp I see it always being somewhere in a callstack that's
> around:
Which test command is it executing exactly? I'm wondering about the
part of the test that exercises statement_timeout. Could we somehow
have broken the ability to detect timeout interrupts ... and if so, how?
Has anyone checked whether the backend still responds to SIGINT
with the patch in place?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2005-10-22 15:24:50 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
| Previous Message | Magnus Hagander | 2005-10-22 14:24:44 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |