Re: Win XP SP2 SMP locking (8.1.4) - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Win XP SP2 SMP locking (8.1.4)
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA357A2@algol.sollentuna.se
Whole thread Raw
In response to Re: Win XP SP2 SMP locking (8.1.4)  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
> >> I'm looking into strange locking, which happens on WinXP SP2 SMP
> >> machine running 8.1.4 with stats_row_level=on. This is the only
> >> combination (# of cpu and stats_row_level) which has problem -
> SMP +
> >> stats_row_level.
> >>
> >> The same test runs fine with one cpu (restarted machine with
> >> /numproc=1) disregarding to stats_row_level option.
> >>
> >> Customer's application loads data into database and sometimes
> process
> >> stopped, no cpu, no io activity. PgAdmin shows current query is
> >> 'COMMIT'.
> >> I tried to attach gdb to postgres and client processes, but
> backtrace
> >> looks useless (see below). Running vacuum analyze of this
> database in
> >> separate process cause loading process to continue ! Weird.
> >>
> >> It's interesting, that there is no problem with 8.2beta1 in all
> >> combinations !  Any idea what changes from 8.1.4 to
> >> 8.2beta1 could affect the problem ?
> >
> > There is a new implementations of semaphores in 8.2. That could
> > possibly be it.
>
> I backported them to REL8_1_STABLE but it doesn't helped. Any other
> idea what to do, or how to debug the situation ?

Unfortunatly, the debugger support for mingw is absolutely horrible. But
you can try process explorer from www.sysinternals.com and see if it'll
give you a decent backtrace. Sometimes it works when others don't.
Either that, or try the Visual Studio or Windows debuggers, they can
usually at least show you if it's stuck waiting on something in the
kernel.

//Magnus


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: Win XP SP2 SMP locking (8.1.4)
Next
From: Richard Huxton
Date:
Subject: Re: pg_dump exclusion switches and functions/types