From: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Win XP SP2 SMP locking (8.1.4) |
Date: | 2006-10-06 09:15:11 |
Message-ID: | Pine.GSO.4.63.0610061313280.18168@ra.sai.msu.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 5 Oct 2006, Magnus Hagander wrote:
>> Hi there,
>>
>> 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 ?
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru)
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-10-06 09:59:52 | Re: Win XP SP2 SMP locking (8.1.4) |
Previous Message | Markus Schaber | 2006-10-06 08:34:20 | Re: pg_dump exclusion switches and functions/types |