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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id 20150728191059.GF4726@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: security labels on databases are bad for dump & restore  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: security labels on databases are bad for dump & restore  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2015-07-28 15:05:01 -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
> >> Yes, I think we should make restoring the database's properties the
> >> job of pg_dump and remove it completely from pg_dumpall, unless we can
> >> find a case where that's really going to break things.
> >
> > CREATE DATABASE blarg;
> > SECURITY LABEL ON blarg IS 'noaccess';
> > ALTER DATABASE blarg SET default_tablespace = space_with_storage;
> > pg_restore
> > -> SECURITY LABEL ON blarg IS 'allow_access';
> > -> ALTER DATABASE blarg SET default_tablespace = space_without_storage;
> >
> > That's probably not sufficient reasons not to go that way, but I do
> > think there's a bunch more issues like that.
> 
> Could you use some complete sentences to describe what the actual
> issue is?  I can't make heads or tails of what you wrote there.

DBA creates a database and sets some properties (security labels, gucs,
acls) on it. Then goes on to restore a backup. Unfortunately that backup
might, or might not, overwrite the properties he configured depending on
whether the restored database already contains them and from which
version the backup originates.

Greetings,

Andres Freund



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Planner debug views
Следующее
От: Robert Haas
Дата:
Сообщение: Re: security labels on databases are bad for dump & restore