Не удалось восстановить резервную копию базы данных на Postgresql-10.0

Я использую postgresql-9.4 (порт 5432) и postgresql-10.0 (порт 5433) на своем компьютере с Linux (RHEL 7.4). Postgresql-9.4 был установлен с использованием репозитория yum, а Postgresql-10.0 был установлен с использованием исходного кода в разных разделах.

Я сделал резервную копию базы данных (dtbase.backup) в Postgresql-9.4, используя его pg_dump, и попытался восстановить его в Postgresql-10.0, используя его pg_restore.

При этом я получаю следующую ошибку:

pg_restore: [archiver] unsupported version (1.13) in file header

Я проверил различные форумы, но не смог найти решение. Любая помощь будет высоко ценится.


linux postgresql pg-restore
person erTugRul    schedule 03.05.2018    source источник
comment
/home/post10/bin/pg_restore — путь по умолчанию для pg_restore для Postgresql-10.   -  person erTugRul    schedule 03.05.2018
comment
/home/post10/bin/pg_restore -l /tmp/dtbase.backup | head -n 20 дает мне ту же ошибку.   -  person erTugRul    schedule 03.05.2018
comment
попробовать взять дум с помощью pg_dump?..   -  person Vao Tsun    schedule 03.05.2018
comment
старый pg_dump работает нормально. Дамп базы данных как dtbase.backup с pg_dump 9.4   -  person erTugRul    schedule 03.05.2018
comment
так что /home/post10/bin/pg_dump создает слишком сложную резервную копию для /home/post10/bin/pg_restore?.. хм... без идей   -  person Vao Tsun    schedule 03.05.2018
comment
Я сделал резервную копию dtbase, используя pg_dump версии 9.4, чтобы восстановить ее в версии 10.0. Я не проверял pg_dump из 10, так как у него нет базы данных для резервного копирования.   -  person erTugRul    schedule 03.05.2018

Ответы (1)


arrow_upward
2
arrow_downward

Вам нужно будет обновить PostgreSQL v10 до версии 10.3, чтобы у вас был коммит b8a2908f0ac735da68d49be2bce2d523e363f67b:

Avoid using unsafe search_path settings during dump and restore.

Historically, pg_dump has "set search_path = foo, pg_catalog" when
dumping an object in schema "foo", and has also caused that setting
to be used while restoring the object.  This is problematic because
functions and operators in schema "foo" could capture references meant
to refer to pg_catalog entries, both in the queries issued by pg_dump
and those issued during the subsequent restore run.  That could
result in dump/restore misbehavior, or in privilege escalation if a
nefarious user installs trojan-horse functions or operators.

This patch changes pg_dump so that it does not change the search_path
dynamically.  The emitted restore script sets the search_path to what
was used at dump time, and then leaves it alone thereafter.  Created
objects are placed in the correct schema, regardless of the active
search_path, by dint of schema-qualifying their names in the CREATE
commands, as well as in subsequent ALTER and ALTER-like commands.

Since this change requires a change in the behavior of pg_restore
when processing an archive file made according to this new convention,
bump the archive file version number; old versions of pg_restore will
therefore refuse to process files made with new versions of pg_dump.

Security: CVE-2018-1058

Ваша установка 9.4 уже использует формат архива 1.13, который ваша установка v10 еще не понимает.

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

person Laurenz Albe    schedule 03.05.2018
comment
Итак, как я могу обновить это, если я установил его из исходного кода? Нужно ли сначала удалить его? Я новичок. - person erTugRul; 03.05.2018
comment
Вы можете удалить версию 10.0 и заменить ее или установить версию 10.3 в другом месте (configure --prefix). - person Laurenz Albe; 03.05.2018
comment
Я решил это без обновления. Я снова сделал резервную копию, используя pg_dump 10.0 вместо 9.4, и на этот раз pg_restore сработало. - person erTugRul; 03.05.2018
comment
Конечно. Тем не менее, вам следует обновиться, так как 10.0 глючит и небезопасна. - person Laurenz Albe; 03.05.2018