Робот отвечал одному человеку пять раз подряд, потому что дедупликация писала в базу запрос, который никогда не выполнялся.

PGW: A PGBACKREST INTERLUDE:

(Andreas Scherbaum, Jimmy Angelakos)

Andreas Scherbaum and Jimmy Angelakos presented a quantitative analysis of the PostgreSQL CommitFest process using data collected from the CommitFest application itself.

The talk showed how PostgreSQL development has scaled significantly over the years. In 2015, CommitFest handled 418 patches from 125 authors, while in 2025 it handled 885 patches from 272 authors — roughly doubling both patch volume and contributor count. However, reviewer and committer capacity has not scaled equally well. The speakers showed that 72.1% of “Needs Review” patches currently have no reviewer assigned, and 196 out of 331 active patches in the current CommitFest have zero reviewers.

Когда несколько клиентов работают с одной записью, проблема часто скрывается не в самом запросе, а в моменте между чтением данных и их сохранением.

Разберём, как тестировать такие ситуации через последовательные и параллельные запросы, какие ответы считать корректными и почему одного успешного HTTP‑ответа недостаточно, чтобы подтвердить безопасность изменений.

restart-hook вернул 202, а сервис всё ещё не отвечает. Повторить запрос — рискнуть вторым перезапуском; закрыть инцидент — записать восстановление, которого не было. На этом конфликте построен recovery в Vigil: система проверяет сервис до и после действия, отсекает устаревшие задачи и останавливает автоматизацию, когда пора звать человека.

При сборе информации со сторонних ресурсов возникают одинаковые для всех проблемы - требуется проверить в своем хранилище, нет ли там уже собранных данных. Идентификаторов нет, источники разные, следовательно работать приходится с текстовыми ключами, поиск по которым гораздо медленней чем по числовым идентификаторам. Проблема обходится применением хэшей - ключевые строки хэшируются и хэш сохраняется в базе вместе с данными. При получении новой порции информации вычисляется хэш и производится индексированный поиск по нему, что намного быстрее поиска по строке.

ххhash очень удобен для этих целей, потому что возвращает 64-битовое число, а не строку, и может быть записан в bigint. Он быстрый, лаконичный, работает "на лету". Большая разрядность практически на нет сводит шансы коллизии, но если она и возникнет, достаточно добавить пробел к тексту для исправления ситуации. Правда есть одна проблема - этой функции нет в postgres "из коробки". На момент, когда мне понадобилась эта функция, я не нашел нужного расширения и написал свое, к тому же было интересно самому выполнить задачу.

Сначала я генерировал xxhash на клиентской стороне. Практически во всех популярных языках xxhash есть, но, например, в Питоне генерируется целое 64-битовое, а bigint в postgres знаковый. И если хэш попадал в верхний диапазон, то при попытке сохранения возникало исключение. Решил просто: