- Shipped
- September 5, 2026 at 2:11 AM UTC
- Author
- Kamo
- Commit
- 31b70a7
Applying DDL bumps the catalog version, and every physical backend still holding the old one fails its next statement with SQLState 40001 — "schema version mismatch for table ...: expected 94, got 93". Hibernate does not retry it, so it reaches a user as a 500. The last occurrence produced 188 of them fleet-wide over fifteen minutes, and it arrived as a bug report about one widget: the failing query is nearly always a boring identity load that runs first on every authenticated request, so whichever feature shouts loudest gets blamed. There is no setting that removes this. Yugabyte's operations guide says concurrent DML during DDL "may use the old schema, the new schema, or encounter temporary schema mismatch errors that require client-side retries", and the two server flags that would narrow the window are not settable at runtime — checked with yb-ts-cli, which refuses both without -force — so changing either costs a restart of a database running one master and one tserver. An earlier note in this codebase blamed HikariCP's maxLifetime and suggested lowering it. That would have done nothing: the tserver runs --enable_ysql_conn_mgr=true, so the Java pools hold LOGICAL connections into Yugabyte's own connection manager and the stale catalog lives in shared physical backends the pool does not own. Costs nothing when nothing is wrong: retrying is driven entirely by an exception a healthy cluster never throws, so the steady-state path is one lambda call. Deliberately narrow about what it will retry — a constraint violation is the database saying the write is wrong, not that it was unlucky, and retrying it turns one fast error into three slow ones. An inconclusive failure is left alone. The same 40001 also covers genuine serialization conflicts and Yugabyte read restarts, both of which reach users as 500s today. Nothing calls it yet; wiring follows.