> > Heads up - I have seen 2 regression hangs. I am checking
> further. Has
> > anyone else run the regression suite with any version of this patch?
>
> Hm, anyone else? It's pretty hard to see how the patch could
> break the regression tests, because they don't exercise
> control-C response time.
>
> Andrew, did you do a full rebuild after applying the patch?
> I don't quite see why that would be needed either, but people
> have seen weird failures from partial rebuilds before ...


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:

.... <- hang
.... <- several more levels
postgres.exe!ExecProcNode
postgres.exe!ExecutorRun
postgres.exe!spi_printtup
postgres.exe!SPI_execute_plan
plpgsql.dll!plpgsql_compile
.... <- several more levels, of course


If I kill the pl/pgsql test, everything else runs fine.
(And removing just this patch makes it run fine again, so it's definitly
this one that causes it)

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Magnus Hagander" <mha@sollentuna.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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:

>"Magnus Hagander" <mha@sollentuna.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



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match