From: Jan de Visser <jdevisser@digitalfairway.com>
To: pgsql-performance@postgresql.org
Subject: Re: Hanging queries on dual CPU windows
Date: Fri, 10 Mar 2006 14:27:39 -0500
User-Agent: KMail/1.9.1
References: <6BCB9D8A16AC4241919521715F4D8BCEA0F847@algol.sollentuna.se>
In-Reply-To: <6BCB9D8A16AC4241919521715F4D8BCEA0F847@algol.sollentuna.se>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200603101427.40357.jdevisser@digitalfairway.com>

On Friday 10 March 2006 13:25, Magnus Hagander wrote:
> > > > Could it be they broke it when they did that????
> > >
> > > In theory, yes, but it still seems a bit far fetched :-(
> >
> > Well, I rolled back SP1 and am running my test again. Looking
> > much better, hasn't locked up in 45mins now, whereas before
> > it would lock up within 5mins.
> >
> > So I think they broke something.
>
> Wow. I guess I was lucky that I didn't say it was impossible :-)
>
>
> But what really is happening. What other thread is actually holding the
> critical section at this point, causing us to block? The only places it
> gets held is while looping the signal queue, but it is released while
> calling the signal function itself...
>
> But they obviously *have* been messing with critical sections, so maybe
> they accidentally changed something else as well...
>
> What bothers me is that nobody else has reported this. It could be that
> this was exposed by the changes to the signal handling done for 8.1, and
> the ppl with this level of concurrency are either still on 8.0 or just
> not on SP1 for their windows boxes yet... Do you have any other software
> installed on the machine? That might possibly interfere in some way?

Just a JDK, JBoss, cygwin (running sshd), and a VNC Server. I don't think t=
hat=20
interferes.

>
> But let's have it run for a bit longer to confirm this does help.=20

I turned it off after 2.5hr. The longest I had to wait before, with less lo=
ad,=20
was 1.45hr.

> If so,=20
> 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=
=20
that would be great.

As a BTW: I reinstalled SP1 and turned stats collection off. That also seem=
s=20
to work, but is not really a solution since we want to use autovacuuming.

>
> //Magnus

jan

=2D-=20
=2D-------------------------------------------------------------
Jan de Visser =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 jdevisser@digitalfair=
way.com

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Baruk Khazad! Khazad ai-menu!
=2D-------------------------------------------------------------