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?
No, we are sure that he didn't do that. As I mentioned above one
connection was terminated, but other ones were hung on update
operations. In this state it was possible to create new connection
from PGAdmin and do some select and update operations. In addition I
can say that we use only read-commited transactions and all operations
are based on prepared statemens which are reused.
It may mean that PGSemaphoreUnlock(PGSemaphore sema) was executed for
unintended sema "object". That's why PGSemaphoreUnlock() for unintended
sema "object" failed and PGSemaphoreUnlock() for intended sema "object"
*never* happens. That would explain why other connections were hung on
update operations.
I think it sounds quite reasonable to be one of possibilities ;)
Regards, Marcin
---------------------------(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
