Контекст и таймауты запросов

Дедлайн истёк — и pgx делает три вещи почти одновременно. Первая: заблокированный вызов в Go разблокируется и вернёт ошибку — при таймауте это context.DeadlineExceeded с текстом context deadline exceeded, при ручной отмене — context.Canceled; пакеты могут оборачивать её своим текстом, поэтому проверяйте через errors.Is, а не сравнением строк. Вторая: соединение уводится из игры — драйвер по умолчанию ставит жёсткий дедлайн на сокет, после чего коннект признаётся негодным; пул при возврате такой коннект уничтожает и по требованию создаст новый. Третья: сервер тоже узнаёт об отмене — прерванное соединение Postgres увидит разрыв и прервёт выполнение запроса сам. Смысл тройки: приложение не ждёт, база не жуёт мёртвый запрос, ресурсы освобождаются с обеих сторон. Побочное следствие важно помнить: после отмены конкретный pgx.Conn мёртв, но живой же пул — недоступность на один запрос не ломает пул целиком, health-проверки из четвёртого урока поднимут замену. И раз коннект после отмены не возвращает нормальный ответ, цепочка rows.Next вернёт false, а rows.Err() из пятого урока покажет причину — пятый урок становится здесь не повторением, а инструментом. Механика по умолчанию устроена честно: обработчик отмены ставит дедлайн прямо на сокет — в дефолтной настройке задержки у него нет, и сокет закрывается. А вот делить один pgx.Conn между горутинами не стоит и рядом: вторая операция на занятом коннекте упадёт с ошибкой conn busy — в исходниках pgconn она честно помечена как возможная только при баге приложения; таймауты здесь не помогут, поможет владение коннектом по одному за раз.

Пара WithTimeout и cancel объясняется устройством таймера: внутри контекста живёт таймер планировщика, и до вызова cancel он считается активным — держит ссылку, память и запись во внутреннем списке таймеров рантайма. Для одного запроса это мелочь, для обработчика, который ставит таймаут на каждый вызов, — утечка по десятку таймеров на запрос. Документация context прямо называет незакрытый контекст утечкой до завершения родителя, а go vet с проверкой lostcancel ругается на пропущенный cancel в коде — обе подсказки появляются на первой же неделе работы. Отсюда рефлекс: defer cancel() пишется сразу после WithTimeout, и между ними не должно быть ни одного return. Полезно знать поведение двойного вызова: cancel идемпотентен, повторный вызов безвреден, поэтому страховка «а вдруг я забыл в другой ветке» бесплатна. На слое HTTP-хендлеров партию таймеров экономит middleware: один WithTimeout на запрос вместо пяти на каждый вызов — вложенность контекстов делает это безопасным, а меньший дедлайн по-прежнему выигрывает. Это же место — правильная точка для логирования: middleware видит разницу между «запрос кончился» и «запрос убит дедлайном» и отдаёт её в метрики, не трогая бизнес-код.

Дедлайны работают вложенно, и это главная мысль блока: контекст-потомок наследует родителя и не может его превысить. HTTP-хендлер получает контекст запроса с уже стоящим дедлайном сервера; внутри он ставит свой WithTimeout на обращение к базе — меньший из двух и есть реальный бюджет. На операцию из нескольких запросов — например, транзакция перевода — бюджет ставится один раз на всю группу: WithTimeout перед Begin, и все tx-вызовы носят этот же qCtx. Отдельный вопрос — освобождение: cancel, который возвращает WithTimeout, обязан вызваться, иначе таймер висит до конца приложения; defer cancel() сразу после создания — рефлекс, а не стилистика. На слое пула контекст работает и на ожидание соединения: pool.Begin и Acquire с истёкшим контекстом не дождутся свободного коннекта и вернут ошибку — при исчерпанном пуле это тот же deadline exceeded, что сбивает с толку, если забыть про очередь ожидания. У ожидания коннекта нет отдельного таймаута-настройки в пуле: бюджет ожидания — это бюджет вашего контекста, отдельной ошибки «не дождался» в pgx нет, есть context deadline exceeded. Практическая расстановка: глобальный фон без дедлайна, дедлайн на юзкейс, при необходимости — ещё один, сжатый, на тяжёлый запрос внутри; каждое звено проверяет errors.Is и отвечает своей ошибкой, а не голым таймаутом наружу.

Здесь самое контринтуитивное место урока. В database/sql отмена контекста, с которым открыли транзакцию, откатывает её автоматически. В pgx это не так: документация Conn.Begin прямо говорит — контекст влияет только на саму команду BEGIN, автоматического отката при отмене нет. Механика такая: дедлайн рвёт выполнение текущего запроса, коннект обычно умирает — и вместе с ним транзакция, откатанная сервером при разрыве. Но разрыв не гарантирован во всех сценариях, и код, который полагается на «сбой — значит откатилось», пишет недетерминированную логику. Правильный каркас: defer tx.Rollback() из тринадцатого урока ставится всегда, независимо от контекста; Rollback на умершем коннекте вернёт ошибку — не страшно, цель в том, чтобы живой коннект никогда не остался с открытой транзакцией. Заметьте асимметрию с database/sql: там откат по отмене встроен в слой адаптера, здесь встроен только разрыв запроса — каркас из defer не опционален. Отдельная ловушка — pgx.BeginFunc из четырнадцатого урока: его контекст обслуживает BEGIN, COMMIT и ROLLBACK, но не ограничивает тело fn — если хотите бюджет на всю операцию, ставьте WithTimeout на контекст до вызова обёртки, и он унаследуется всеми запросами внутри. Оба факта сходятся в одно правило: контекст ограничивает отдельные вызовы, а каркас транзакции — ваша ответственность.

Контекст — дедлайн клиента, но Postgres умеет ставить лимит и сам: SET statement_timeout = '2s' ограничивает выполнение запроса на сервере, и команда, превысившая лимит, получает ошибку canceling statement due to statement timeout уже от базы. Зачем вторая страховка, если есть первая? Клиентский таймаут защищает приложение, но не базу: горутина без дедлайна гонит запрос, пока соединение живо; statement_timeout защищает базу от всех клиентов сразу — отчётов аналитиков, чужих сервисов, консольной сессии коллеги. Ставится по-разному: глобально в конфиге, на роль ALTER ROLE analytics SET statement_timeout, на сессию SET, и разумная практика — жёсткий потолок для отчётных ролей и щедрый или отсутствующий для сервисных. Рядом живут два соседних лимита: idle_in_transaction_session_timeout рвёт транзакцию, которая сидит без дела, — прямая защита от приложения, открывшего Begin и ушедшего в HTTP-вызов, — тот самый случай из живого примера тринадцатого урока; lock_timeout ограничивает ожидание блокировки, чтобы запрос не висел в очереди к чужой строке вечно. Оба дополняют statement_timeout: он режет долгое выполнение, они — долгое бездействие и долгое ожидание. Есть нюанс совместимости: таймаут на сервере не спасает, если затык в сети до базы — пакет едет, но долго; клиентский контекст в этой ситуации единственный, кто заметит. Взаимодополнение — правильный вывод: контекст режет затыки по дороге, statement_timeout режет тяжёлые планы на сервере, а лог медленных запросов из двадцать четвёртого урока покажет, кого из них вы недооценили.