Re: Win XP SP2 SMP locking (8.1.4)
От | Rocco Altier |
---|---|
Тема | Re: Win XP SP2 SMP locking (8.1.4) |
Дата | |
Msg-id | 6E0907A94904D94B99D7F387E08C4F57018337C3@FALCON.INSIGHT обсуждение исходный текст |
Ответ на | Win XP SP2 SMP locking (8.1.4) (Oleg Bartunov <oleg@sai.msu.su>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: