Дано:
PG 9.4
2 сервера на win64, тестовый и боевой
база ~ 20 гб (мелкая, т.к. пока на начальном этапе)
время от времени база на тестовом сервере синхронизируется через backup/resture.
pg_dump -a -w -b -Ft -f db.bk db

dropdb --if-exists db
pg_restore.exe -C -d postgres -e db.bk

Проблема.
C одного момента рестор обламывается.
pg_restore: [архиватор (БД)] сбой команды COPY для таблицы ... : ОШИБКА: не
т данных для колонки "..."
КОНТЕКСТ: COPY таблица, строка 711728: "1336641 2 22 \N \N
\N 1 2 16777215 \N \N \N \N \N
\N \N \N \N \N"
смотрел это место в файле глазами, принципиальных отличий от предыдущих строк не заметил.
?

ОКТОГЕН, с ключом -Fc размер бэкап получился в 10 раз меньше, что подозрительно :)

А пока - начал извращения с частичными бэкапами (где проблемные таблицы исключены ключом -T )
Проблемные таблицы бэкапил отдельно в текстовый формат и ресторил psql-ем.

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

В целом удалось восстановить базу вышеуказанным образом.
Причём это работает только с текстовым форматом, с бинарным вылетает на трёх таблицах.
Ладно, пусть теперь работает так, но "что это было?" (c)

vyegorov,

эт проверил сразу же.
даже в файле бэкапа дублей не было.

Lonepsycho, по моей схеме восстановление шло так:
0. dropdb
1. restore -C -s (только метаданные)
2. restore непроблемных таблиц, двоичный формат
3. psql проблемных таблиц, текстовый формат

на 3 шаге на одной из этих пробл.табл. psql и выдала сей мессидж, причём только для одной записи.
выходит, я что-то напутал и запустил один из скриптов 3 шага второй раз.

сейчас соберу всё в один батник и проверю.

...товарищи, есть объяснение, почему с двоичным форматом не прокатывает, а с текстовым - да ...?

qwwq,

да, забыл. Ключик --disable-triggers - используется.
перед проблемными таблицами в psql alter table disable triggers all

выходит, я что-то напутал и запустил один из скриптов 3 шага второй раз.
сейчас соберу всё в один батник и проверю.
...проверил, отработало без ошибок. Значит тогда таки напутал

ОКТОГЕН_avz,
Ключик -Fc спасает, рекомендую.
Восстановление в несколько потоков - существенно быстрее
Позавчера, получив с ключом -Fc размер бэкапа в несколько раз меньше, я усомнился в его валидности и не стал проверять восстановление, а зря.

Сегодня руки дошли, проверил - restore отработало без ошибок.
Так что спасибо, буду использовать -Fc.

PS почему размер меньше выходит - я так понял, потому, что запись идёт в реально бинарном формате, в то время как при -Ft по факту текстом.

ОКТОГЕН, спасибо, так и сделал.

Павел Лузанов,

в час укладывается - пока ладно :)