mirror of
https://github.com/stablyai/orca.git
synced 2026-10-02 16:02:15 +00:00
Jinwoo-H
e18a2268e4
Two changes from a second review round, both of which make the guard safer with less machinery than the alternatives I was considering. The stand-down was a transaction-wide latch: one locked read whose projection omits cell_id muted every statement after it, so a genuinely descending write in the same transaction went unreported. Scoping it to the statement is strictly safer and needs no alert policy to compensate, because the only effect of a missing `held` entry is to REMOVE a report, never to invent one -- the case that looks like a counterexample, where an unreadable read takes a row and a later write names it, is a true violation with misleading attribution rather than a false one. "Select only the columns you need" is a natural future edit, and it should cost one statement of coverage, not a whole transaction of silence. Violations now count violating TRANSACTIONS. Merging attempts with a max cannot inflate, but it can zero out an observed violation: an attempt that violates and then hits a retryable 55P03 may be followed by a clean attempt down a different branch, which would erase the only signal this ships for. The gate is zero-versus-nonzero, so what must survive is "this transaction violated at least once". Magnitude stays in the distinct-signature log. Also: ORDER BY now tolerates an alias, because `ORDER BY cell.cell_id ASC` orders identically and rejecting it would throw in tests on correct SQL. And the comment claiming a JOIN locks no cell row is wrong -- Postgres FOR UPDATE without OF locks every table in the FROM list -- so it now records what the narrow reading really does, along with the WITH ... SELECT shape it cannot see. Both under-report, and neither exists in relay today.