Re: dumping database privileges broken in 9.6

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: dumping database privileges broken in 9.6
Дата
Msg-id CAOuzzgrb36pcx-JiW7LxRg_6F7Je3rRfkg55Q6jkDb=_U0eMWg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: dumping database privileges broken in 9.6  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
Noah, all,

On Saturday, July 2, 2016, 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

Will work on it tomorrow but for a deadline for next status update, I'll say Tuesday (which I expect is when I'll commit the fix) as it's a holiday weekend in the US. 

Thanks!

Stephen

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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <