The following bug has been logged online:

Bug reference: 2371
Logged by: Brock Peabody
Email address: brock.peabody (AT) npcinternational (DOT) com
PostgreSQL version: 8.1
Operating system: Windows Server 2003
Description: database crashes with semctl failed error
Details:

The full text of the error message is:

FATAL: semctl(167894456, 4, SETVAL, 0) failed: A non-blocking socket
operation could not be completed immediately.

I have a program that inserts/updates/deletes a large number of records to a
large database (~100 GB). The program works, but after it runs for a few
hours it starts getting this error message. Once this happens the database
is unusable to all clients until it is restarted.

I found this documented bug:

http://archives.postgresql.org/pgsql...2/msg00185.php

but I'm not sure if it is related to my problem or not.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

""Brock Peabody"" <brock.peabody (AT) npcinternational (DOT) com> wrote
Can you reliablly reproduce the problem? If so, we may come up with a
testing patch to it. We encounter similar problems before but it is hard to
reproduce.

Magnus? As Bruce suggested, we can plug in a check-EINTR-loop here in
semctl():

/* Quickly lock/unlock the semaphore (if we can) */
if (semop(semId, &sops, 1) < 0)
return -1;

Regards,
Qingqing



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

I can here . I'm trying to figure out a way for someone to repeat it
outside my environment but I'm afraid it's got something to do with
timing. I have 50 threads that are collecting data. If I give each one
its own connection to the database the problem happens quickly. If they
all share one connection the problem does not happen.

Do you think this is a Windows only problem?

Thanks,
Brock


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

"Brock Peabody" <brock.peabody (AT) npcinternational (DOT) com> writes:
Perhaps you could whittle down your app into a testbed that just sends
dummy data with about the same timing as the real app?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

I think I'm starting to get a better understanding of problem. It looks
like one of the threads is trying to insert a pathological (~1,800,000)
number of records in one transaction in a table while the other threads
are also reading from and writing to that table. I'll try to get
something simple to reproduce this behavior.


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

""Peter Brant"" <Peter.Brant (AT) wicourts (DOT) gov> wrote
There is a "Win32 semaphore patch" in the patch list, but we are lack of
evidence to prove its usefulness. If you can try to apply it to your *test*
server (8.0.*, 8.1.* are all ok), that would be very helpful to see the
result.

Regards,
Qingqing



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster