Hi,
retested:
yes, this is still an issue in 9.3.5, same deadlock errors occured.
Do you need to extract some simplified reproducible testcase?
Best Regards, Andrej
Hi Bill,
thanks for your answer.
most often caused by something earlier in the transactions
need all of the statements in each transaction
It would be great if we could reveal an application error.
Whole transactions I've already posted (in postgres log:
log_min_duration_statement=0).
Hi,
now I've checked release-notes of 9.3.5 (my version 9.3.4)- found a fix
which probably could lead to my deadlocks:
Fix race condition when updating a tuple concurrently locked by another
process (Andres Freund,Álvaro Herrera)
How can I make sure I've run into this bug?
Andrej Vanek wrote:
Hi,
now I've checked release-notes of 9.3.5 (my version 9.3.4)- found a fix
which probably could lead to my deadlocks:
Fix race condition when updating a tuple concurrently locked by another
process (Andres Freund,Álvaro Herrera)
How can I make sure I've run
On Tue, 23 Sep 2014 20:00:27 +0200
Andrej Vanek andrej.vanek...@gmail.com wrote:
Hi,
My application runs many concurrent sessions with the same transaction code
starting with an update statement.
I would expect locking and serialization of those transactions. But I get
unexpected
Hi,
My application runs many concurrent sessions with the same transaction code
starting with an update statement.
I would expect locking and serialization of those transactions. But I get
unexpected deadlocks.
As opposed to *http://momjian.us/main/writings/pgsql/locking.pdf
