Re: dumping database privileges broken in 9.6

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: dumping database privileges broken in 9.6
Дата
Msg-id 20160712201819.GA4028@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: dumping database privileges broken in 9.6  (Noah Misch <noah@leadboat.com>)
Ответы Re: dumping database privileges broken in 9.6  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
All,

* Noah Misch (noah@leadboat.com) wrote:
> On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> > > Do this:
> > >
> > > CREATE DATABASE test1;
> > > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
> > >
> > > Run pg_dumpall.
> > >
> > > In 9.5, this produces
> > >
> > > CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> > > REVOKE ALL ON DATABASE test1 FROM PUBLIC;
> > > REVOKE ALL ON DATABASE test1 FROM peter;
> > > GRANT ALL ON DATABASE test1 TO peter;
> > > GRANT TEMPORARY ON DATABASE test1 TO PUBLIC;
> > >
> > > In 9.6, this produces only
> > >
> > > CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> > > GRANT TEMPORARY ON DATABASE test1 TO PUBLIC;
> > > GRANT ALL ON DATABASE test1 TO peter;
> > >
> > > Note that the REVOKE statements are missing.  This does not
> > > correctly recreate the original state.
> >
> > I see what happened here, the query in dumpCreateDB() needs to be
> > adjusted to pull the default information to then pass to
> > buildACLComments(), similar to how the objects handled by pg_dump work.
> > The oversight was in thinking that databases didn't have any default
> > rights granted, which clearly isn't correct.
> >
> > I'll take care of that in the next day or so and add an appropriate
> > regression test.
>
> This PostgreSQL 9.6 open item is past due for your status update.  Kindly send
> a status update within 24 hours, and include a date for your subsequent status
> update.  Refer to the policy on open item ownership:
> http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com

Attached is a patch to address this.

After much consideration and deliberation, I went with the simpler
solution to simply dump out the database privileges based on what a new
creation of those privileges would yield, resulting in output similar to
pre-9.6.  We document that template1 is allowed to be dropped/recreated,
which greatly complicates using pg_init_privs to record and produce a
delta against the initdb-time values, as we lose the connection between
pg_init_privs and the "template1" database as soon as it is dropped
(something which can't be done with objects in that catalog).

Comments welcome.

Thanks!

Stephen

Вложения

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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: DO with a large amount of statements get stuck with high memory consumption
Следующее
От: Tom Lane
Дата:
Сообщение: Re: GiST index build versus NaN coordinates