Magnus Hagander wrote:
I've looked at the code there, and can't find a clear problem. One way it
could happen is if the actual PGSemaphoreUnlock() is called once more than
needed.
CC:ing to hackers for this question:
Any chance that's happening? If this happens with SysV semaphores, will
they
Magnus Hagander wrote:
Hmm, PGSemaphoreUnlock() actually ignore this error, only log that it
happens.
No. It does ereport(FATAL) which terminates the backend.
Oh, now I see, sorry :) Indeed on this one connection we receive
exception "FATAL: could not unlock semaphore", after that r
Marcin Waldowski wrote:
Doesn't the postmaster restart all other backends due to the FATAL
error?
Are you saying that you can no longer make new connections to the
server,
or is the problem coming from that the aplpication doesn't like that the
server kicked out all connections?
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
No, it's definitly the right primitive. But we're creating it with a max
count of 1.
That's definitely wrong. There are at least three reasons for a PG
process's semaphore to be signaled (heavywe
