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

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id 20150721060628.GC1339234@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: security labels on databases are bad for dump & restore  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Ответы Re: security labels on databases are bad for dump & restore  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
> > Consistency with existing practice would indeed have pg_dump ignore
> > pg_shseclabel and have pg_dumpall reproduce its entries.
> 
> I think that makes sense, but what about other DATABASE level info
> such as COMMENT?  Should that also be ignored by pg_dump as well?  I'm
> specifically thinking of the discussion from the following thread:
> 
> http://www.postgresql.org/message-id/20150317172459.GM3636@alvh.no-ip.org
> 
> If COMMENT is included then why not SECURITY LABEL or others?

In any given situation, we should indeed restore both pg_database comments and
pg_database security labels, or we should restore neither.  Restoring neither
is most consistent with history, but several people like the idea of restoring
both.  I won't mind either conclusion.

> > In a greenfield, I would make "pg_dump --create" reproduce pertinent entries
> > from datacl, pg_db_role_setting, pg_shseclabel and pg_shdescription.  I would
> > make non-creating pg_dump reproduce none of those.
> 
> I think the bigger question is "Where is the line drawn between
> pg_dump and pg_dumpall?".  At what point does one tool become the
> other?

That question may be too big for me.



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: "make check" changes have caused buildfarm deterioration.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Support for N synchronous standby servers - take 2