Hello.
I've made some analysis of PostgreSQL code. It looks like void
PGSemaphoreUnlock(PGSemaphore sema) from backend\port\win32_sema.c was
executed one time more than needed.
Error code 298 means "Too many posts were made to a semaphore":
http://msdn2.microsoft.com/en-us/library/ms681382.aspx (sorry for
posting microsoft links ;))
Below is an example when it happens:
http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.kernel/2004-02/0406.html
If I understand it correctly it means that function ReleaseSemaphore
(http://msdn2.microsoft.com/en-us/library/ms685071.aspx) which is
executed from PGSemaphoreUnlock, was executed one time more than needed.
I'm afraid than problem may lie above win32_sema.c :(
Regards, Marcin
Marcin Waldowski wrote:
The following bug has been logged online:
Bug reference: 3242
Logged by: Marcin Waldowski
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.3 and 8.2.1
Operating system: Windows XP SP2
Description: FATAL: could not unlock semaphore: error code 298
Details:
Hello.
After some time of performace test of our aplication (50 concurrent database
connections making lots of quick transactions with prepared statements) we
found problem in PostgreSQL log - "could not unlock semaphore: error code
298". After that connections were hanged blocked on update operations.
We are investigating problem now. What another information should we
provide?
Log from 8.2.1
2007-04-19 08:52:11 FATAL: could not unlock semaphore: error code 298
2007-04-19 08:52:11 STATEMENT: COMMIT
2007-04-19 08:52:11 WARNING: AbortTransaction while in COMMIT state
Log from 8.2.3
2007-04-19 10:56:13 FATAL: could not unlock semaphore: error code 298
2007-04-19 10:56:13 STATEMENT: update sometable set a = a + $1, b = b + $2,
c = c + $3 where id = $4
Regards, Marcin
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
