From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Jan de Visser" <jdevisser(at)digitalfairway(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PERFORM] Hanging queries on dual CPU windows |
Date: | 2006-03-13 17:27:03 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA0F85C@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > Looking a my system while testing this it still loooked
> like it was
> > > hanging on that plac ein the code, even though I saw no
> problems. So
> > > I'm not convinced we can actually trust the stacktrace from the
> > > non-default threads. So I don't think this patch will
> actually work
> > > :-( But it's worth a try.
> >
> > I'm afraid you're right. Hangs again :(
>
> I now have the toolchain set up, so if you want me to try
> stuff, please let me know. Resolving this is important to us.
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.
If you can, it'd be interesting to see it from the pre-SP1 install as
well - once it hangs.
> On a whim, I replaced InitializeCriticalSection with
> InitializeCriticalSectionAndSpinCount, since MSDN told me
> that would be better for SMP. No joy.
No, that should make no difference - except possibly a tiny difference
in speed.
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.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Peter | 2006-03-13 17:43:25 | Re: Transaction eating up all RAM |
Previous Message | Peter | 2006-03-13 16:43:24 | Transaction eating up all RAM |