Re: [PERFORM] Hanging queries on dual CPU windows

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

Responses

Browse pgsql-hackers by date

  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