Postgres 40001 kills the transaction, so Node's retry wrappers are decoration

The isolation knob and the retry loop sit at different levels of the stack, and that is the whole problem. A decorator can take an isolation level as an argument ^[3], so SERIALIZABLE is cheap to switch on. The loop cannot go in the same place, because it has to wrap the call to the decorated function, not live inside it. TypeORM has the same boundary: `dataSource.transaction()` owns the callback, and the retry belongs to whatever called it ^[9]. Read that way, the open request for auto retry on deadlock and serialization errors ^[2] is asking a library to do something from a position where it cannot see the transaction it would need to restart.

The naive fix is not neutral. Postgres aborts the transaction rather than the statement when it raises 40001 ^[4], and every statement afterwards on that connection comes back as 25P02, commands ignored until end of transaction block ^[5]. So a three-attempt wrapper around one UPDATE fires two doomed retries, sleeping 50 milliseconds and then 100 between them, and finally throws 25P02 ^[6][7]. You have spent 150 milliseconds ^[7] to replace the one error code that tells an operator what to do with one that tells them nothing.

The version result is the part worth keeping even if nobody in your shop touches SERIALIZABLE. The author's test asserted that the failure surfaces at COMMIT, which is a reasonable inference from how SSI tracks read and write dependencies ^[10]. It passed on 14, 16 and 17, and failed on 15 ^[11]: three of four tested majors agreed with a model that was wrong ^[12]. Postgres raises 40001 as soon as its machinery spots the dangerous structure, which can be at commit after every statement has already returned success, or at the conflicting statement, depending on the version, the plan and the interleaving ^[13]. The replacement test asserts only that the failing query was the COMMIT or the conflicting UPDATE ^[14], which is the honest invariant. A suite pinned to a single minor version would have shipped the wrong one as fact.

What is left is unglamorous. The caller rolls back, takes a fresh connection and transaction, and re-runs the entire callback from the top ^[9]. The cost moves to whoever wrote that callback, because its contents now run more than once and have to survive it. The ecosystem's current answer, per the same writeup, is to stay on READ COMMITTED and not think about write skew ^[8], which is cheaper until an application needs the guarantee it declined to turn on.