Разберёшь дамп на команды и найдёшь ту, что испортила shop.
Логический дамп — набор команд, которые создают базу заново: таблицы, строки, счётчики, ключи. Файлов самой базы в нём нет. pg_dump записывает эти команды, pg_restore выполняет. Поэтому дамп можно поднять на другом сервере и в другой базе.
Ключ -Fc у pg_dump выбирает формат custom — сжатый архив, который читает pg_restore. Он показывает оглавление архива (--list, в шапке — из какой базы и когда снят архив, Archive created at) и превращает архив обратно в текст SQL: -f - печатает его на экран, -t orders — только одну таблицу. Без ключа -F pg_dump пишет сразу простой текст SQL.
Загляни внутрь дампа
В ~/backup выведи оглавление дампа shop.dump, потом — его команды SQL, которые создают таблицы, загружают строки и выставляют счётчики.
Сначала предположи
Какими командами дамп загружает строки таблиц?
Теперь начни упражнение, выполни команду и сверь прогноз с выводом.
Эти команды pg_restore и выполнил по порядку в живой shop. CREATE TABLE упал: таблицы есть — already exists. COPY упал на первой строке: id 1 занят — duplicate key. Ключи тоже уже были.
А setval прошёл. Последовательность orders_id_seq — счётчик, из которого база берёт id для нового заказа. Дамп вернул её к вчерашним 5, и следующий заказ получил id 6, который уже занят. Ошибки pg_restore было видно сразу, а порчу — только на следующей вставке.
Из orders удалили все строки — DELETE FROM orders, — а сама таблица осталась. Что сделает pg_restore -d shop shop.dump со вчерашним дампом?
-
CREATE TABLEупадёт: таблица есть. СтрокиCOPYзагрузит в существующую таблицу. -
duplicate keyбывает, когда id занят. ПослеDELETEid в orders свободны, иCOPYпройдёт; упадёт толькоCOPYв customers. -
Без
--exit-on-errorpg_restore идёт дальше после ошибки: в начале урока после упавшегоCREATE TABLEон выполнил иCOPY, иsetval.
pg_restore выполняет команды дампа по одной и после ошибки идёт дальше. CREATE TABLE и ключи упадут, COPY в пустую orders пройдёт, setval выставит счётчик на 5: в orders снова будут вчерашние 5 заказов.