> On Monday 13 March 2006 12:27, Magnus Hagander wrote:
> > Great. That'll certainly help - now you don't have to wait for
> > binaries from me.
> >
> > What I'd be interested in seeing is new stackdumps from a version
> > where
> > you:
> > 1) Do *not* have the patch for mutexes applied
> > 2) Have removed "static" from all the function devlarations in
> > signal.c and socket.c, bnoth in src/backend/port/win32.
>
> I did that, and the interesting thing is that:
> 1. It takes much longer to hang.

?! That shouldn't be related :-)

> 2. Once it hangs, the stacktraces are the same.

Hmm. That's weird :-(
Did you do a make clean? Sometimes needed to get the port stuff in,
mingw messes up sometimes.

> 3 (and this is the kicker). The thing starts working again
> after a couple (+/-
> 5) minutes ?????????

Interesting. And you get nothing in the logs? (pg_log / eventlog)


> 1. can probably be explained by the fact that I didn't
> compile with any optimization. Can you tell me what CFLAGS
> the binary distro uses?

You can use pg_config to see that.

>2. I don't know (are there other tools I can use?), and
Not really, but try the make clean.

> 3. I frankly don't understand. I know
> for sure that with the stock 8.1.3 it would not revive itself
> (I let it running for a *long* time).

Very interesting.


> > If you can, it'd be interesting to see it from the pre-SP1
> install as
> > well - once it hangs.
>
> I've never seen a pre-SP1 install hang.

Oh, hang on, what I meant was with the post-SP1 hang but with stats
disabled. :-)


> > Do you have the ability to test 8.0 on the same machine? We
> did some
> > extensive modifications to the signal stuff between 8.0 and
> 8.1, it'd
> > be interesting to see if that changed things.
>
> I seem to remember we made ourselves dependend on 8.1
> somehow, but will check.

Ok. Please do.

//Magnus

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

Magnus Hagander wrote:
>> On Monday 13 March 2006 12:27, Magnus Hagander wrote:
>>> Great. That'll certainly help - now you don't have to wait for
>>> binaries from me.
>>>
>>> What I'd be interested in seeing is new stackdumps from a version
>>> where
>>> you:
>>> 1) Do *not* have the patch for mutexes applied
>>> 2) Have removed "static" from all the function devlarations in
>>> signal.c and socket.c, bnoth in src/backend/port/win32.
>> I did that, and the interesting thing is that:
>> 1. It takes much longer to hang.
>
> ?! That shouldn't be related :-)
>
>> 2. Once it hangs, the stacktraces are the same.
>
> Hmm. That's weird :-(
> Did you do a make clean? Sometimes needed to get the port stuff in,
> mingw messes up sometimes.
>
>> 3 (and this is the kicker). The thing starts working again
>> after a couple (+/-
>> 5) minutes ?????????
>
> Interesting. And you get nothing in the logs? (pg_log / eventlog)

There's a report on -bugs ([BUGS] Random hang during commit /
b.lin@dl.ac.uk) that might well be related to this.

--
Richard Huxton
Archonet Ltd

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