Didn't the stats communication process get redone for 8.2?
Or atleast some time-out related stuff.
Since the problem seems to be related to stats_row_level being on, I
wonder if the problem might be in that sub-system. I am guessing that
vacuum is pushing some more stats through, which might explain how that
allows it to unfreeze.
-rocco
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of
> Magnus Hagander
> Sent: Friday, October 06, 2006 6:00 AM
> To: Oleg Bartunov
> Cc: Pgsql Hackers
> Subject: Re: [HACKERS] Win XP SP2 SMP locking (8.1.4)
>
>
> > >> 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> http://archives.postgresql.org
