I'm taking care of a web application which uses Postgres and the SERIALIZABLE transaction isolation level. I am thinking about reducing the transaction isolation level REPEATABLE_READ. Is there a way to analyze current logs to see if there were issues that were already prevented by having SERIALIZABLE instead of REPEATABLE_READ?
In my logs, I see those kinds of issues:
A) could not serialize access due to concurrent update
B) could not serialize access due to read/write dependencies among transactions
DETAIL: Reason code: Canceled on conflict out to pivot 13059031, during read.
C) could not serialize access due to read/write dependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during write.
D) could not serialize access due to read/write dependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during conflict out
checking.
Is maybe one of them only caused by serialization anomalies?
