- Ya
- 5 Septemba 2026, 03:22 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 19ddb30
Applying DDL bumps the catalog version, and backends still holding the old one fail their next statement with SQLState 40001 until they are recycled. The last occurrence cost 188 errors fleet-wide over fifteen minutes and was reported as a single widget being broken. **************** (from 3600) bounds how long a physical backend can go on holding a stale catalog to five minutes rather than an hour. Note this is a CONNECTION MANAGER setting, not a client one: the tserver runs --enable_ysql_conn_mgr=true, so the services' Hikari pools hold LOGICAL connections and the stale catalog lives in shared backends the pools do not own. Lowering Hikari's maxLifetime, the obvious guess, would have done nothing. **************** carries catalog versions on the master->tserver heartbeat so the new version propagates promptly instead of on a lazy path. Neither is settable at runtime — yb-ts-cli refuses both without -force — so this costs a restart of the master and the tserver, and with replicas: 1 on each that is a full database outage. Taken deliberately, with the owner's approval. These narrow the window; they do not remove it. Yugabyte's position is that concurrent DML during DDL "may encounter temporary schema mismatch errors that require client-side retries", which is what TransientDbRetry is for.