Re: pg_dump\pg_restore large objects

Сергей Бурладян wrote:
> Sergej Kandyla <sk(at)hlsrv(dot)com> writes:
>
>
>> Слегка запутался с дампами и к своему позору обнаружил,
>> что при обычном дампе (plain text) large objects не экспортируются!!!
>>
>
> Это не так. LO экспортируются по умолчанию, и в этом легко убедиться
> запустив pg_dump без параметров, например:
> $ pg_dump | grep lo_open
> SELECT pg_catalog.lo_open('16651', 131072);
>
> вообще, это зависит от параметров pg_dump. Например если Вы сохраняете
> только одну таблицу, то LO экспортироваться не будут.
>
> подробнее можно прочитать здесь: http://www.postgresql.org/docs/current/static/app-pgdump.html
>

Спасибо за ответ.

Я, видимо, начитался старых манов из гугла:

http://www.postgresql.org/docs/8.0/static/backup.html
22.1.4. Caveats
For reasons of backward compatibility, pg_dump does not dump large
objects by default. To dump large objects you must use either the custom
or the tar output format, and use the -b option in pg_dump. See the
pg_dump reference page for details. The directory contrib/pg_dumplo of
the PostgreSQL source tree also contains a program that can dump large
objects.

и отсюда сделал такие выводы.

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

Все вылечилось после перехода на бинарный формат. Ни одной ошибки.

>> Бекап, сделанный при помощи custom format:
>> pg_dump -Fc -b -f ${file} ${db}
>> 759M database.dump
>>
>
> Это сжатый текст. LO в двоичном виде. Чтобы увидеть сколько оно занимает
> без сжатия добавьте параметр -Z0
>
>
>> Бекап, сделанный при помощи tar format:
>> pg_dump -Ft -b -f ${file} ${db}
>> 870M database.dump.tar
>>
>
> Это несжатый текст, LO в двоичном виде + текстовой файл со схемой данных.
>

Не понял, момента.
Для переноса базы достаточно одного из таких дампов.
Из ваших слов выходит что -Ft -b содержит дополнительые схемы
данных, которые отсутствуют в бекапе "-Fc -b"..

>> И наконец, plain-text бекап:
>> pg_dump -c -f ${file} ${db}
>> 2.8G database.sql (plain text) - откуда???
>> даже если потом сжать этот бекап (tar.gz), то получается 1.1G...
>>
>>
>
> Это несжатый текст, почти такой же как в tar формате, только ещё и LO
> тут в текстовом виде (а это значит что один двоичный байт LO в худшем
> случае в текстовом виде занимает пять байт «\\000»).
>
ясно!

>> 3) Восстановление:
>> даже указывая опцию
>> -c, --clean, если база уже содержит данные, то импорт заканчивается ошибками.
>>
>> pg_restore -c -d mydatabase db.dump
>> ....
>> pg_restore: [archiver] could not create large object 16887
>>
>> Если же базу данных предварительно грохнуть, и потом создать заново, то все ок.
>> Это что, фича такая?
>>
>
> Возможно, Вы предоставили мало информации об ошибке. Вообще, ключ -c
> подразумевает что очищаемая база соответствует той, что в резервной
> копии. Если они различаются — то часть объектов не будет удалена так как
> удаляются только те объекты, которые есть в резервной копии.
>

Указывая эту опцию: -c, --clean clean (drop)
database objects before recreating
я ожидал что будет нечто подобное как в мускиле, и вроде бы оно так и
есть...

DROP TABLE...
CREATE TABLE...

Однако, если база уже была создана и содержала данные,

то ни дамп, сделанный посредством, pg_dump --clean
ни pg_restore -c ... binary.dump

не отрабатывают корректно (проверял на разных PG серверах.).

Мне такое поведение не ясно.
Для консистентного импорта бекапа, нужно сначала базу грохнуть, потом
создать заново
и тогда уже импортить. В этом случае порядок.

Хотя может такое поведение и вполне оправдано.

>> 4) права доступа.
>> Если в бекапе встречались различные предоставления привилегий, в духе:
>> ALTER TABLE mydbtable OWNER TO myuser_role
>>
>> А на новой базе такой роли нету (или я умышленно хочу сделать для импортируемой
>> базы другого владельца),
>> как будет правильно поступать..?
>>
>
> Создать нужную роль, а потом её переименовать. Если такая роль уже есть
> и Вы хотите её изменить - то тут сложнее :)
>
да, все оказалось проще.
аля,
CREATE ROLE newrole
CREATE DATABASE $DBNAME WITH OWNER=newrole

pg_restore -U newrole -O -d $DBNAME db.dump

Субьективные выводы:
1. Не нашел почти никаких преимуществ в plain-text бекапах (кроме как
цели руками его посмотреть)
binary dump в сумме получается заметно быстрее и портабельнее,
занимает меньше места.
Перенастроил систему бекапов на этот формат.

2. Импорт бекапов нужно делать, только предварительно удалив и заново
создав базу данных.
(про pg_dump -С я знаю, но считаю не очень портабельным, поэтому
не использую).

Спасибо!