Re: pg_dump\pg_restore large objects

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

> 1)
> делая бекапы, с указанием custom format, и --blob
> pg_dump -Fc -b -f ${file} ${db}
>
> можно ли быть уверенным что все нужные данные попадают в бекап?

Смотря что Вы имеете ввиду под «нужные», например, можно быть уверенным
что определения пространств таблиц (TABLESPACE) и роли туда точно НЕ попадут.

> 2) Не понимаю, почему такие расхождения по размеру бекапов:
>
> Сама база:
> # du -sh /srv/pgsql/data/base/
> 1.1G /srv/pgsql/data/base/

Это бинарные данные, частично возможно сжатые + индексы.

> Бекап, сделанный при помощи 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 в двоичном виде + текстовой файл со схемой данных.

> И наконец, 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
подразумевает что очищаемая база соответствует той, что в резервной
копии. Если они различаются — то часть объектов не будет удалена так как
удаляются только те объекты, которые есть в резервной копии.

> 4) права доступа.
> Если в бекапе встречались различные предоставления привилегий, в духе:
> ALTER TABLE mydbtable OWNER TO myuser_role
>
> А на новой базе такой роли нету (или я умышленно хочу сделать для импортируемой
> базы другого владельца),
> как будет правильно поступать..?

Создать нужную роль, а потом её переименовать. Если такая роль уже есть
и Вы хотите её изменить - то тут сложнее :)

> Я, конечно, понимаю, что при создании базы я указываю и владельца для нее, и
> весь импорт будет присвоен указанному владельцу,
> но все же.

--
С уважением, Сергей Бурладян