Two sections described routines nobody built, and Serializable lets an invariant through

[dmitrat]

Items 6 and 7 of Docs/FIX-PLAN-FROM-SITE-FINDINGS-2026-08-15.md. No behaviour changes — what lands is what was measured, in the XML comments, in WitSQL.md, and in tests that fail if any of it drifts.

Isolation: two of the four outcomes contradicted what was written down

	outcome
Serializable / RepeatableRead — read an empty range, another commits into it, then write and commit	refused, serialization failure
the same, but the first transaction only reads	commits cleanly, correctly — a read-only transaction can always be ordered first
Serializable and Snapshot — two transactions, same rows read, different rows written	both commit; the invariant is gone
either level, both write the same row	second is refused

Write skew is permitted at Serializable. The standard doctors example holds here exactly: each transaction checks that somebody else is on call, each takes a different doctor off, both commit, and the ward ends with nobody on call. Nothing detects it, because neither transaction touched what the other wrote. An application whose correctness rests on an invariant across rows has to enforce it itself.

And the comment that was simply wrong. WitIsolationLevel.RepeatableRead promised that read locks are held for the transaction's duration. Every level above ReadCommitted here is optimistic — the conflict is found at commit and raised as an exception. A caller who believed the comment wrote no retry at all, because a lock blocks and never fails.

WhatEachIsolationLevelPreventsTests pins all six. These pass by construction and that is not the point of them: each names one outcome with the reason in its message, so a change to the MVCC validation shows up here, named, rather than as a surprise in somebody's application. The write-skew cases are labelled as pinning permitted behaviour, so that a future change which starts refusing it is a visible decision. REPEATABLE READ turned out to refuse the phantom-then-write as well — not known before this run, now a parameterised arm.

WitSQL.md §§ 22–23 described a design that was considered and not taken

Both said "not implemented as of 2026-07-29" and described table-valued functions, IF/WHILE bodies, OUT parameters and multiple result sets. Routines shipped in 11.0.0 and are none of that:

• a function body is one expression, which is exactly what makes calling one safe from a path evaluated once per row — no statements, no transaction, no nesting budget;
• a procedure body is a sequence of statements, and the last statement's result is the call's result.

Replaced rather than edited, because nothing in them survived.

Sequences had no section at all

The ID-generation table documented INCREMENT and LASTINCREMENT without ever connecting them to CREATE SEQUENCE, and never mentioned NEXTVAL/CURRVAL — the names anyone arriving from PostgreSQL tries first. § 23.1 now states the whole surface, measured:

CREATE SEQUENCE [IF NOT EXISTS] name [START WITH n]
ALTER SEQUENCE name RESTART [WITH n]
DROP SEQUENCE [IF EXISTS] name

No INCREMENT BY — it is a syntax error — no MINVALUE, no MAXVALUE, no CYCLE, and the step is always 1.

Three entries in KnownIssues

Each is behaviour to build around rather than a defect to fix by surprise: write skew at every level; partial indexes the planner never selects, so they cost every write and are never read; and no hit-rate counter in either paged cache — a dashboard plotting one is plotting something that does not exist.

The rule underneath both sections

A note carrying a date rather than a version is a claim that stopped being checked the day it was written. Both of these were, for over a year.

Core 2371, Engine 2549.

🤖 Generated with Claude Code