Свой gRPC-wire в Route, отсечение props до агрегата в redb.Core, Tsak закрыт по умолчанию, второй фасад у Identity. И 3.7.0, отозванный через день.

За три дня у экосистемы сменилось три номера: 3.7.0, 3.7.1 и 3.7.2. Первый отозван, живой номер 3.7.2. Ниже разбор того, что в этой линии вышло, в порядке зависимостей: интеграционный движок redb.Route, хранилище redb.Core, рантайм redb.Tsak и OpenID-сервер redb.Identity. Все четыре продукта идут на одном номере, 66 пакетов.

Начну с того, почему номеров три.

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

Восстановление данных буду делать с помощью второго PostgreSQL контейнера. Если кратко - данные WAL и base_backup будут прокидываться с помощью volume и контейнер будет стартовать с новыми данными.

Пока что рабочий стенд будет ограничиваться PostgreSQL 17 в Docker (без S3, Kubernetes, автоматизации и т.п), потом возможно сделаю дополнительные статьи, охватывающие более сложные production случаи.

В первой статье я объяснял кэш через холодильник. Продолжу тем же способом. Сейчас будет про индексы, а потом про то, почему индекс есть, а база его игнорирует.

Статья для тех, кто индексы ставил, но EXPLAIN читал по диагонали.

У банков и ритейлеров, с которыми я работала, почти всегда одна и та же боль: данные о клиенте размазаны по CRM, core-banking и платёжным системам, и никто не может ответить на простой вопрос — а что мы вообще знаем об этом клиенте прямо сейчас. Чтобы попрактиковаться в решении этой задачи и показать подход публично, я собрала pet-проект: end-to-end пайплайн, который строит единую витрину Customer 360 из синтетических данных.

Сразу оговорюсь: все данные генерируются локально скриптом и полностью синтетические. Кода или данных работодателя в проекте нет — это самостоятельная реализация архитектуры, которую я использую в повседневной работе DWH/data-аналитика.

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

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 знаковый. И если хэш попадал в верхний диапазон, то при попытке сохранения возникало исключение. Решил просто: