kepr / 3cbde3e49ed6

fix two real issues an independent Opus review found in the write-pool rewrite: (1) statement_timeout was never actually set on pooled write connections — the doc comment said it was, but lock() never called .exec(), meaning every HTTP write ran with Postgres's unbounded default timeout, silently dropping the exact defense-in-depth that motivated the original SET on app.conn; now issued right after each fresh acquire. (2) lock()'s retry-on-acquire-failure loop was unbounded — during a Postgres outage it would park every httpz worker thread forever (nav lookups alone call lock() on nearly every authenticated page), eventually starving the whole daemon, the same wedged-daemon symptom as the historical self-deadlock reached by a different path. Bounded to a 30s total window; past it, lock() panics (aborting the process) rather than hanging silently, so a process manager restart kicks in instead of a livelocked daemon that still looks up to anything not touching the DB. Verified: no statement_timeout warnings logged across concurrent write-path requests on a local daemon; full suite still green against no-PG and real Postgres (636/639, same baseline). Bump to v1.56.212

dev · 5 weeks ago · 2026-07-17 · 15.1 MB

session: phase C write-path connection pool · agent: claude-sonnet-5

parent: 3f9b450c6e78