Some of my transactions are declared as SERIALIZABLE. Sometimes I get back class 40 errors such as 40001 serialization_failure and 40P01 deadlock_detected (I haven't seen other codes yet), particularly when I'm stress testing the system by doing lots of concurrent transactions.
If I understood the manual correctly, this is to be expected. When these errors happen, I'm therefore suppose to retry the transaction. My doubt is whether all of class 40 errors are "normal" when handling SERIALIZABLE transactions. In other words, can I just assume that any class 40 error should lead me to retry the transaction, or is this assumption correct only for a subset of class 40 errors?
Per the error codes section of the manual the 40xxxx SQLSTATE category is "transaction rollback".
It includes the error codes:
40000 transaction_rollback40002 transaction_integrity_constraint_violation40001 serialization_failure40003 statement_completion_unknown40P01 deadlock_detectedOf these, I would not generally expect transaction_integrity_constraint_violation to trigger a retry, since that'll be raised when a DEFERRED foreign key check causes a transaction to abort when commit is attempted. This is unlikely to go away if retried unless your application has issues with concurrency and locking design.
I haven't encountered statement_completion_unknown; I'd suggest looking it up.
Personally I would retry on deadlock_detected and serialization_failure only.
In the meantime, Kevin Grittner gave me an unequivocal answer in the pgsql-general mailing list. To summarise, both errors 40001 and 40P01 are "normal" when issuing serializable transactions in a concurrent setting.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With