- Зачем:
- генерация с нуля занимала часы, boarding_passes были пустыми, данные
пропадали после docker compose down/up.
- Что:
- обновлён demodb до коммита 866e56f, добавлен патч install_connstr_no_hardcode.
- BOOKINGS_INIT_DAYS увеличен до 60, BOOKINGS_JOBS по умолчанию 2.
- добавлен seed-дамп bookings/seed/demo.sql.xz (42 MB, xz вместо 7z).
- make bookings-init восстанавливает из дампа (~18 сек) и применяет GUC из .env.
- make bookings-generate — генерация с нуля для разработчиков.
- generate_next_day.sql: COMMIT после continue(), pg_sleep(3) для jobs>1, synchronous_commit=on + CHECKPOINT.
- bookings-check-jobs: добавлена валидация нечисловых значений BOOKINGS_JOBS.
- bookings-init теперь вызывает bookings-check-jobs как prerequisite.
- синхронизированы внутренние документы (коммит demodb, init_days=60).
- Проверка:
- make bookings-init && make bookings-generate-day BOOKINGS_JOBS=2.
- make test.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
7.2 KiB
План исправления: генератор demodb (bookings) остаётся пустым
Контекст
В стенде используется демобаза bookings из репозитория postgrespro/demodb, закреплённая на коммите 866e56f7fe54596a1d2a88f5f32f4aa3b2698121 (см. DEMODB_COMMIT в Makefile).
Инициализация источника для ETL выполняется двумя способами:
make bookings-init— быстрое восстановление из seed-дампа (~18 сек, рекомендуется для студентов);make bookings-generate— полная генерация с нуля (для разработчиков):- клонирует demodb в
bookings/demodb/; - пытается применить патчи из
bookings/patches/; - запускает
install.sqlв контейнереbookings-db; - выставляет GUC-параметры (
gen.connstr,bookings.start_date/init_days/jobs); - запускает
/bookings/generate_next_day.sql(должен сгенерировать минимум 1 день данных).
- клонирует demodb в
Симптомы (как в TODO)
- после
make bookings-generateтаблицаbookings.bookingsостаётся пустой; - патчи
bookings/patches/engine_jobs1_sync.patchиbookings/patches/install_drop_if_exists.patchпадают при применении; - из‑за этого DAG
bookings_to_gp_stageвалится на проверках (источник пустой).
Предварительный диагноз (что уже видно)
-
engine_jobs1_sync.patchне является валидным unified diff (в hunk’ах нет номеров строк вида@@ -N,M +N,M @@), поэтомуpatchотвечает:patch: **** Only garbage was found in the patch input. -
install_drop_if_exists.patchустарел относительно закреплённого коммита demodb: вinstall.sqlуже естьDROP DATABASE IF EXISTS demo;, поэтому hunk “не находится” и патч не накатывается. -
Ошибки патча сейчас замаскированы в
Makefileчерез|| true, поэтомуmake bookings-generateможет завершаться “успешно”, хотя критичные правки в demodb не применились.
Цель фикса
make bookings-init(восстановление из дампа) иmake bookings-generate(генерация с нуля) воспроизводимо создают и наполняютdemo.bookings.bookings(>0 строк).- Если патчи не применяются — процесс останавливается с понятным сообщением, что делать дальше.
- Патчи соответствуют закреплённому коммиту demodb и применяются идемпотентно.
План диагностики (чтобы быстро подтвердить проблему)
- Чистое воспроизведение:
make cleanrm -rf bookings/demodbmake bookings-generate
- Проверка данных:
make bookings-psql- выполнить:
SELECT COUNT(*) FROM bookings.bookings;SELECT min(book_date), max(book_date) FROM bookings.bookings;
- Проверка патчей (без изменения файлов):
patch -d bookings/demodb -p1 --dry-run < bookings/patches/engine_jobs1_sync.patchpatch -d bookings/demodb -p1 --dry-run < bookings/patches/install_drop_if_exists.patch
Ожидаемо: сейчас dry-run показывает “garbage in patch” и/или “Hunk FAILED”.
План решения
Шаг 1. Пересобрать патчи под закреплённый демо‑коммит
Собираем патчи через git diff, чтобы получился корректный unified diff.
bookings/patches/engine_jobs1_sync.patch:
- Добавить/подтвердить 2 изменения в
engine.sql:busy()игнорирует текущий backend:AND pid <> pg_backend_pid().continue()приjobs = 1выполняетprocess_queue(end_date)синхронно и пишет заметный маркер в лог (Job 1 (local): ok), иначе — оставляет текущую логику черезdblink.
bookings/patches/install_drop_if_exists.patch:
- Поменять строку (в актуальном
install.sql):- было:
DROP DATABASE IF EXISTS demo; - стало:
DROP DATABASE IF EXISTS demo WITH (FORCE);
- было:
Шаг 2. Сделать make bookings-generate fail-fast на проблемах с патчами
В Makefile:
- убрать
|| trueу применения патчей; - при ошибке патча — завершать
makeс ненулевым кодом и короткой подсказкой:- “удалите
bookings/demodbи повторитеmake bookings-generate”, - “если не помогло — проверьте, что
DEMODB_COMMITне менялся и патчи собраны под него”.
- “удалите
Шаг 3. Добавить “защиту от тихого пустого результата”
После запуска /bookings/generate_next_day.sql (в Makefile или внутри SQL):
- выполнить проверку
COUNT(*)поbookings.bookings; - если 0 — завершаться ошибкой с подсказкой, куда смотреть (патчи/логи генератора).
Цель: чтобы проблема не уезжала дальше в DAG’и и DQ‑проверки, а ловилась сразу при init.
Проверка (критерии готовности)
make clean && rm -rf bookings/demodb && make bookings-generateзавершается без ошибок.make bookings-psql→SELECT COUNT(*) FROM bookings.bookings;возвращает> 0(для обоих способов:bookings-initиbookings-generate).make bookings-generate-dayдобавляет следующий день:max(book_date)сдвигается на +1 сутки.
./scripts/e2e_smoke.shпроходит до проверкиstg.bookings(или хотя бы DAGbookings_to_gp_stageперестаёт падать на “источник пустой”).
Откат (если нужно быстро вернуть стенд в рабочее состояние)
- Временно отключить применение патчей в
Makefileи явно предупреждать, что генерация может быть нестабильной (нежелательно для студентов). - Или зафиксировать альтернативный
DEMODB_COMMIT, под который уже готовы патчи (делать только вместе с обновлением документации и проверкой, что генерация стабильна).