Postgres Lost Update Verdict

Decides whether a database write can SILENTLY LOSE a concurrent update. Pure function over the shape of the statement and the isolation level: no I/O, no driver.

THE MEASUREMENT. A real PostgreSQL server. One row, balance 100. Two concurrent transactions, each reading, pausing, then writing back what it read plus its own amount. Correct answer: 180.

    default_transaction_isolation   read committed

    tx A: SELECT balance -> 100 ... UPDATE SET balance = 100 + 50
    tx B: SELECT balance -> 100 ... UPDATE SET balance = 100 + 30

    ACTUAL: 130

The +50 is gone. Both committed. NEITHER RAISED ANYTHING. Read committed guarantees you never read UNCOMMITTED data; it does not stop two transactions reading the same COMMITTED row and both writing back. That is the shape of every "add to balance", "increment counter", "append to array", "set status based on current status" written as read-then-write.

MEASURED CORRECT: `UPDATE SET balance = balance + 50` gave 180, and `SELECT ... FOR UPDATE` before the read gave 180. One statement works because there is no window between read and write -- there is no separate read. The lock works because the second transaction waits.

SERIALIZABLE MAKES IT LOUD. IT DOES NOT MAKE IT RIGHT.

    ERROR:  could not serialize access due to concurrent update
    result: 130

PostgreSQL detected the conflict and aborted one transaction -- so the silent wrong answer became a visible error. AND THE BALANCE IS STILL 130, because the aborted work simply did not happen. SERIALIZABLE converts a lost update into a RETRYABLE ERROR; only the retry makes it correct. Raising the isolation level without a retry loop trades a silent wrong number for a dropped write and a failed request. Better -- and not the fix it is usually described as. So this package reports serializable WITHOUT a retry as a finding, and credits the retry rather than the level.

ALSO MEASURED: `ON CONFLICT DO NOTHING ... RETURNING` returns NO ROW when the row already exists -- an empty result while the record was present both times. RETURNING only returns rows the statement touched, and DO NOTHING touched none. A caller reading "no row returned" as "the insert failed" takes an error path, inserts again, or threads a null id onward. Reported even when nothing is concurrent, because it is not a concurrency question.

IT REFUSES rather than guesses on unknown concurrency, saying plainly that for anything reachable from a web request or a job queue the answer is almost always yes. And a "no concurrent writers" claim is answered SAFE WITH THE CAVEAT that it covers every path to the row -- background jobs, admin tools and retries included.

VERIFIED: 21 tests, every one of 8 mutations observed FAILING before restore.

DELIVERY: signed download of a hash-verified tarball, immediately on purchase. Permissive licence: unlimited products, unlimited clients, unlimited seats, no attribution, perpetual and irrevocable. One restriction, do not republish the source as source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function evaluateWriteSite(site: WriteSite): Verdict;

  export type IsolationLevel = "read-committed" | "repeatable-read" | "serializable" | "unknown";
  export type Verdict = | { status: "SAFE";