Skip site navigation (1) Skip section navigation (2)

Re: pg_dump\pg_restore large objects

From: eshkinkot(at)gmail(dot)com ( Сергей Бурладя =?utf-8?B?0L0=?=)
To: Sergej Kandyla <sk(at)hlsrv(dot)com>
Cc: pgsql-ru-general(at)postgresql(dot)org
Subject: Re: pg_dump\pg_restore large objects
Date: 2011-04-07 20:57:13
Message-ID: 87lizlpyom.fsf@home.progtech.ru (view raw or flat)
Thread:
Lists: pgsql-ru-general
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
>
> А на новой базе  такой роли нету (или я умышленно хочу сделать для импортируемой
> базы другого владельца),
> как будет правильно поступать..?

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

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

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

In response to

Responses

pgsql-ru-general by date

Next:From: Sergej KandylaDate: 2011-04-08 14:17:14
Subject: Re: pg_dump\pg_restore large objects
Previous:From: Dmitriy IgrishinDate: 2011-04-04 16:50:07
Subject: Re: Pg documentation in russian

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group