Re: fsync and semctl errors with 8.1.5/win32

Jeremy,

My company runs a 200 gig data warehouse. We are running 8.1.2. We were
seeing hanging transactions and occasional semctl errors.

We were also running it on Windows Server 2003. We ended up rolling
back service pack 1 and it seems to have taken care of the hanging
transactions and we haven't seen a semctl error in a while.

Worth a shot if it applies to you.

Brad Russell
Programmer Analyst
NPC International

-----Original Message-----
From: pgsql-bugs-owner(at)postgresql(dot)org
[mailto:pgsql-bugs-owner(at)postgresql(dot)org] On Behalf Of Thomas H.
Sent: Thursday, November 30, 2006 9:11 AM
To: Jeremy Haile; pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] fsync and semctl errors with 8.1.5/win32

> Did you run into problems where transactions would hang? If so, did
> those disappear in 8.2?

well, i wasn't really able to exactly determine under what conditions
that
xlog bug appeared in our case. tho it always was when lots of data is
imported at once within one transaction. under normal load i've never
seen
the xlog bug. as far as i know it was some sort of lifelock: as with the

other error messages, another postgres.exe kept a lock of the xlog file,

which the bgwriter-process wanted to rename which lead to the complete
halt
of the db system, due to the importance of xlog/bgwriter. you can force
an
unload of the locked xlog file handle in processmon, and postgresql will

resume "normally".

i had a transaction lately that created 7gb of xlog-files (vacuum full
of a
mid-sized table) without any xlog-lockup, so i guess this problem is
really
fixed in the latest 8.2 build :-)

if you have hanging transactions but other db activity works well, i
would
rather guess its a side effect of the other file problems with the
relation-files that can't be renamed. i've never been able to see any
impact
of that error message. even when it appears 10 times a second everything

seems "ok". but on the other side, in our case, we use the database as a
web
backend and have always around 20-30 concurrent connections, so its hard
to
debug.

- thomas

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend