Re: pg_dump / restore of empty database gives errors

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: pg_dump / restore of empty database gives errors
Дата
Msg-id Pine.LNX.4.44.0302232115240.1618-100000@peter.localdomain
обсуждение исходный текст
Ответ на Re: pg_dump / restore of empty database gives errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump / restore of empty database gives errors  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Tom Lane writes:

> Hmm.  So the real story here is that the permissions set up by initdb
> for PUBLIC are actually an illegal state: postgres has granted
> permissions to public that it isn't allowed to.

Yes, the way the permissions are initialized in the catalog templates

DATA(insert OID = 11 ( "pg_catalog" PGUID "{=U}" ));
DATA(insert OID = 99 ( "pg_toast" PGUID "{=}" ));
DATA(insert OID = 2200 ( "public" PGUID "{=UC}" ));

produce an invalid state.  I hadn't thought that this would create a
problem for pg_dump, but I will hurry up fixing it.  (I will probably put
explicit GRANT commands into initdb.)

> (There may also be an issue with the order in which pg_dump issues its
> revoke/grant operations, ie, there might be legal combinations that it
> can't reproduce.)

If you don't do manual surgery on aclitem's then I am convinced that it is
not possible to arrive at an undumpable state.  This is a consequence of
the way it's implemented.

-- 
Peter Eisentraut   peter_e@gmx.net




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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: ILIKE
Следующее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: Re: Loss of cluster status