Re: security labels on databases are bad for dump & restore

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id CA+TgmobD-XgYTbzDvR+Z6WBXA01wXoAw7Tf8a5C9_RrtCO9Bmw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: security labels on databases are bad for dump & restore  (Noah Misch <noah@leadboat.com>)
Ответы Re: security labels on databases are bad for dump & restore  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Список pgsql-hackers
On Thu, Jul 30, 2015 at 2:49 AM, Noah Misch <noah@leadboat.com> wrote:
> What exact formula did you have in mind?  It must not be merely
>
> 1. "pg_dumpall -g"
> 2. "pg_dump" (without --create) per database
>
> which _never_ works: it emits no CREATE DATABASE statements.  Perhaps this?
>
> 1. "pg_dumpall -g"
> 2. Issue a handwritten CREATE DATABASE statement per database with correct
>    encoding, lc_ctype and lc_collate parameters.  All other database
>    properties can be wrong; the dump will fix them.
> 3. "pg_dump" (without --create) per database
>
> That neglects numerous database properties today, but we could make it work.
> Given the problems I described upthread, it's an inferior formula that I
> recommend against propping up.  I much prefer making this work completely:
>
> 1. "pg_dumpall -g"
> 2. "pg_dump --create" per database

Gah, OK, I see your point.  But we better document this, because if
you need a PhD in PostgreSQL-ology to take a backup, we're not in a
good place.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Volatility of pg_xact_commit_timestamp() and pg_last_committed_xact()
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"