Re: pg_dump / restore of empty database gives errors

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Rod Taylor <rbt(at)rbt(dot)ca>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump / restore of empty database gives errors
Date: 2003-02-23 23:36:04
Message-ID: Pine.LNX.4.44.0302232115240.1618-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmx(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-02-24 02:21:55 Re: Loss of cluster status
Previous Message Josh Berkus 2003-02-23 21:02:27 Re: ILIKE