From: | "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov> |
---|---|
To: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #2371: database crashes with semctl failed error |
Date: | 2006-04-10 20:00:36 |
Message-ID: | 443A7314020000BE00002BCF@gwmta.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi all,
We were bitten by this same bug over the weekend (PG 8.1.3 / Windows
Server 2003). The exact error was:
FATAL: semctl(170688872, 6, SETVAL, 0) failed: A non-blocking socket
operation could not be completed immediately.
The start of the errors corresponded to a nightly "vacuum analyze"
(both Saturday and Sunday) run. Things appeared to clear up after the
"vacuum analyze" completed.
One thing of note is that the semctl parameters were identical across
both nights (and a smaller incident Monday morning). The Monday morning
occurence was also somewhat odd in that not much should have been going
on then. Also, three other servers which faced identical update/insert
transaction streams did not have any trouble. The select load might
have been higher on the server that failed though.
One question I had:
In src/backend/port/win32/sema.c, semctl() is implemented in terms of a
call to semop(). However, the man page for semctl() doesn't list EAGAIN
and EINTR as possible error returns, whereas for semop() it does. Is
that just a mistake in the man page or a problem with the Win32
emulation call?
(See also
http://archives.postgresql.org/pgsql-bugs/2006-02/msg00233.php )
I'm afraid we're in the same category as everyone else with no good way
to reproduce the bug, but is there anything else we could do if this
happens again?
Pete
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick Headley | 2006-04-11 03:53:37 | BUG #2386: pg_restore doesn't restore large objects |
Previous Message | Anton | 2006-04-10 10:50:21 | BUG #2385: libpq, lo_write bug |