2026-08-25 · run 2026-08-25-s3-statement-timeout

S3: `statement_timeout` cannot half-migrate this path

Summary

⚠ CONCLUSION OVERTURNED 2026-08-26. It does produce one. At 2,000,003 users a statement_timeout of 500 ms, 200 ms or 50 ms leaves DATABASECHANGELOG at 157 of 211 with migration_model on 26.0.0 and the server dead — seven times in ten identical runs.

The measurements below are correct and the reasoning from them is not. The statement that dies is ALTER TABLE CREDENTIAL ADD VERSION INTEGER DEFAULT 0, which executes in 0.177 ms and waits about a second for an AccessExclusiveLock held by an autovacuum worker — Postgres evicts a blocking autovacuum only after deadlock_timeout, and statement_timeout is charged for the wait. This record measured statement durations on a single run that happened to be uncontended.

See 2026-08-26-s3-revisited-autovacuum-lock-wait. Everything below stands as a measurement of an uncontended migration; nothing below should be quoted as a conclusion about statement_timeout.

S3 was written to produce the half-migrated schema our failure-class notes name. It does not produce one. On this path, at 2,000,003 users, the longest single SQL statement the migration issues is 2.142 ms. There is no statement_timeout value that lands between "too short to start" and "long enough to finish": at 2 ms Keycloak fails before applying any changeset, at 3 ms it completes the whole migration. The band that would leave a schema half-applied is empty.

This is the second scenario in a row (after S1/S2) that fails to reproduce a failure class we have been citing.

Environment

Procedure

./bin/restore.sh baseline-26.0.0-sqlseed-2m
docker compose exec -T db psql -U keycloak -c "alter system set log_min_duration_statement=0" -c "select pg_reload_conf()"
./bin/upgrade.sh 26.7.1                       # measurement run
docker compose logs db | grep 'LOG:  duration:' | sort -gr   # rank statements

# then, per timeout value:
./bin/restore.sh baseline-26.0.0-sqlseed-2m
docker compose exec -T db psql -U keycloak -c "alter role keycloak set statement_timeout='<T>'"
./bin/upgrade.sh 26.7.1

What we could not observe

No half-migrated schema, at any timeout value. The empty band is a consequence of every statement in the migration falling inside 1.8–2.2 ms: the parse-phase reads and the DDL writes are the same order of magnitude, so a timeout tight enough to kill a changeset is also tight enough to kill the parse that precedes it. That coincidence is a property of this pair at this scale, not a general law, and we did not test whether it holds elsewhere.