Транзакции пиннят соединения: уровни изоляции из Go и повтор 40001 и 40P01

Одна транзакция — одно пришпиленное соединение

Весь урок висит на одном механическом факте: BeginTx забирает из пула одно соединение и пиннит его до Commit или Rollback. Каждый стейтмент на *sql.Tx едет по этому соединению — именно поэтому транзакция видит свои незакоммиченные записи, и именно поэтому пул беднее на единицу всю её жизнь. Арифметика из крючка следует напрямую: пул на 20 соединений, где каждая транзакция оборачивает 9 секунд HTTP, даёт жёсткий потолок около 2,2 транзакции в секунду на весь процесс, и все посторонние запросы стоят за ними в очереди. Правило, которое это предотвращает: между Begin и Commit — только операторы базы и дешёвый CPU; никаких HTTP-вызовов, публикаций в Kafka, файлового I/O. Если процессу нужны внешние вызовы плюс атомарность — это машина состояний: закоммитить строку pending, сделать вызов, затем вторая короткая транзакция для финализации.

Каноническая форма:

func transfer(ctx context.Context, db *sql.DB, from, to int64, amt int64) error {
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer tx.Rollback() // после успешного Commit вернёт sql.ErrTxDone — сознательный no-op

	if _, err := tx.ExecContext(ctx,
		`UPDATE accounts SET balance = balance - $1 WHERE id = $2`, amt, from); err != nil {
		return err // любой ранний return: defer откатит и освободит пришпиленное соединение
	}
	if _, err := tx.ExecContext(ctx,
		`UPDATE accounts SET balance = balance + $1 WHERE id = $2`, amt, to); err != nil {
		return err
	}
	return tx.Commit()
}

defer tx.Rollback() сразу после BeginTx — паттерн, который стоит усвоить навсегда. Rollback после успешного Commit — не баг: Tx уже разрешён, поэтому вызов возвращает sql.ErrTxDone и не делает ничего. Эта идемпотентность и есть замысел: одна отложенная строка покрывает каждый ранний return и каждую панику между Begin и Commit, а счастливый путь не платит за неё ничем. Альтернатива — флаг committed или ручной откат в каждой ветке ошибки — это ровно тот код, который забывает одну ветку и утекает пришпиленное соединение плюс открытую серверную транзакцию с её локами.

Изоляция: что вы просите и что даёт Postgres

Прежде чем выбрать уровень изоляции, спроси себя: от какой именно аномалии конкурентного доступа ты защищаешься? Ответ подскажет нужный уровень — и обязательство по повтору, которое с ним придёт. database/sql позволяет запросить уровень изоляции переносимо; драйвер транслирует или отказывает:

tx, err := db.BeginTx(ctx, &sql.TxOptions{
	Isolation: sql.LevelSerializable, // pgx выполнит: BEGIN ISOLATION LEVEL SERIALIZABLE
	ReadOnly:  true,                  // Postgres пропустит механику записи; бесплатная подсказка планировщику
})

На другой стороне приезжает семантика Postgres, и её стоит знать точно:

• Read committed (по умолчанию). Каждый стейтмент видит свежий снапшот. Два SELECT в одной транзакции могут разойтись; read-modify-write в виде SELECT-потом-UPDATE молча теряет конкурентные обновления. Лекарства живут в SQL: один атомарный UPDATE ... SET x = x + 1 или SELECT ... FOR UPDATE, чтобы сперва залочить строку.
• Repeatable read. Один снапшот на всю транзакцию — чтения стабильны. Но если конкурентная транзакция закоммитила запись в строку, которую вы затем обновляете, ваша падает со SQLSTATE 40001 (serialization_failure). Уже на этом уровне повтор перестаёт быть опциональным.
• Serializable. Postgres гоняет SSI (Serializable Snapshot Isolation — сериализуемая изоляция на снапшотах) поверх снапшотов, отслеживая зависимости чтения/записи между конкурентными транзакциями. Он даёт настоящую сериализуемость — и оставляет за собой право обрывать транзакции, которые по отдельности не сделали ничего плохого, тем же 40001. Документация прямолинейна насчёт контракта: приложения на этом уровне обязаны быть готовы повторять транзакции. Serializable без цикла повторов — латентный генератор 500-х, который срабатывает только под конкуренцией, то есть только в проде.

Ожидания локов, дедлоки и цикл повторов

Две разные патологии медленных транзакций постоянно путают. Ожидание лока — тихая очередь: ваш UPDATE блокируется, пока транзакция, держащая лок строки, не закоммитится — без ошибки, просто задержка (ограничивайте через lock_timeout; вытаскивайте на свет через log_lock_waits). Дедлок — цикл: транзакция A держит строку 1 и хочет строку 2, B держит строку 2 и хочет строку 1. Postgres обнаруживает цикл спустя deadlock_timeout (по умолчанию 1 с), выбирает жертву и убивает её со SQLSTATE 40P01 — выжившая продолжает нормально. И 40001, и 40P01 повторяемы по замыслу: база говорит «это чередование проиграло, попробуй ещё раз», а не «эта операция неверна». Что делает retry-хелпер несущим паттерном этого юнита:

func withTx(ctx context.Context, db *sql.DB, opts *sql.TxOptions, fn func(tx *sql.Tx) error) error {
	var err error
	for attempt := 1; attempt <= 4; attempt++ {
		err = func() error {
			tx, err := db.BeginTx(ctx, opts)
			if err != nil {
				return err
			}
			defer tx.Rollback()
			if err := fn(tx); err != nil {
				return err
			}
			return tx.Commit()
		}()
		if !retryable(err) || ctx.Err() != nil {
			return err
		}
		// бэкофф с джиттером: партнёры по дедлоку, ретраящие в ногу, столкнутся снова
		time.Sleep(time.Duration(attempt*attempt) * 25 * time.Millisecond)
	}
	return fmt.Errorf("transaction gave up after 4 attempts: %w", err)
}

func retryable(err error) bool {
	var pgErr *pgconn.PgError
	return errors.As(err, &pgErr) &&
		(pgErr.Code == "40001" || pgErr.Code == "40P01") // serialization_failure, deadlock_detected
}

Вес несут три детали. Классификация идёт через errors.As по типизированной ошибке драйвера и сверяет коды SQLSTATE — никогда не по подстроке в тексте ошибки, который ломается между версиями драйвера и локалями. Замыкание перезапускается целиком, поэтому fn обязана быть безопасной к повтору: никаких побочных эффектов вне самой транзакции (письмо, отправленное внутри fn, уйдёт по разу на каждую попытку). А бэкофф с джиттером не случаен — два партнёра по дедлоку, ретраящие по одинаковому расписанию, снова встретятся на тех же строках.