Re: [PERFORM] Hanging queries on dual CPU windows - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [PERFORM] Hanging queries on dual CPU windows
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA0F85C@algol.sollentuna.se
Whole thread Raw
Responses Re: [PERFORM] Hanging queries on dual CPU windows
Re: [PERFORM] Hanging queries on dual CPU windows
List 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


pgsql-hackers by date:

Previous
From: Lukas Smith
Date:
Subject: Re: Fwd: DB2-style INS/UPD/DEL RETURNING
Next
From: "Rodrigo Hjort"
Date:
Subject: Restoring a Full Cluster on a Different Architecture (32 x 64)