| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Magnus Hagander <mha(at)sollentuna(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:40:42 |
| Message-ID: | 435A5D7A.8060007@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>"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?
>
>
It appears to hang in blockme() - so your guess seems correct.
>Has anyone checked whether the backend still responds to SIGINT
>with the patch in place?
>
>
After it hung, I issued pg_ctl -m fast -w stop and it stopped cleanly.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-10-22 15:46:50 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
| Previous Message | Magnus Hagander | 2005-10-22 15:24:50 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |