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>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PERFORM] Hanging queries on dual CPU windows
Date: 2006-03-12 14:40:19
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA0F856@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > If so,
> > we could perhaps recode that part using a Mutex instead of
> a critical
> > section - since it's not a performance critical path, the
> difference
> > shouldn't be large. If I code up a patch for that, can you re-apply
> > SP1 and test it? Or is this a production system you can't
> really touch?
>
> I can do whatever the hell I want with it, so if you could
> cook up a patch that would be great.
>
> As a BTW: I reinstalled SP1 and turned stats collection off.
> That also seems to work, but is not really a solution since
> we want to use autovacuuming.

Ok, I've coded up a patch that changes the code to use a mutex instead.
Patch attached. You can get a precompiled postgres.exe at
http://www.hagander.net/download/postgres.exe_mutex.zip. You need to
copy this file to postmaster.exe as well - they are supposed to be
identical. It's based off a snapshot of 8.1-stable.

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.

(Oh, and I moved the thread over to -hackers, seems more correct at this
time)

//Magnus

Attachment Content-Type Size
mutex.patch application/octet-stream 4.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2006-03-12 14:56:10 ERROR: record type has not been registered on CVS head
Previous Message Marc G. Fournier 2006-03-12 09:59:04 Re: PostgreSQL Anniversary Summit, Call for Contributions