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
|
Список | 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 по дате отправления: