Has this been addressed? I don't see any changes in initdb.sh or
pg_namespace.h.
---------------------------------------------------------------------------
Peter Eisentraut wrote:
> 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
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
