storage-postgres: the data path assumes READ COMMITTED and does not pin it; put_create_race fails under a repeatable read default #570

Summary

The PostgreSQL backend's data path assumes READ COMMITTED and does not set it. On a server whose default_transaction_isolation is repeatable read, crates/storage-postgres/tests/put_create_race.rs fails 9 of 9 on main 744ea29 with Internal("error returned from database: could not serialize access due to concurrent update") (SQLSTATE 40001) from the put path, where a READ COMMITTED server passes all nine.

Measured 2026-10-25 on pgvector/pgvector:pg16 started with -c default_transaction_isolation='repeatable read'; the same tests pass on the same image with the default setting.

Cause

PostgresEngine::new builds both pools with PgPoolOptions::new().connect(...) and no isolation setting, and the data-path transactions open with pool.begin(). The setting is operator-reachable from the connection string (options=-c default_transaction_isolation=...), ALTER DATABASE, ALTER ROLE and postgresql.conf. The crate does pin a level where it wants one (begin_with("BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY") in backup_engine.rs and data/transactions.rs), and #569 pins READ COMMITTED on update_table's transaction, so the mechanism is there; the rest of the control plane and the data path inherit the default.

Under REPEATABLE READ the create-race retry (an INSERT ... ON CONFLICT loser re-reading the winner's row) and every SELECT ... FOR UPDATE after a prior statement in the same transaction see the first statement's snapshot, and a row committed after it raises 40001 instead of being re-read, which the engine answers as a 500.

Fix shape

Either pin READ COMMITTED once per connection (after_connect on the pool running SET default_transaction_isolation = 'read committed'), which covers every transaction the crate opens, or open each transaction with begin_with("BEGIN ISOLATION LEVEL READ COMMITTED"). The pool hook is one place; state in the operator docs that the backend requires it. A CI job variant that starts the container with repeatable read would pin it.