From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dumpall --clean is completely broken |
Date: | 2009-04-11 20:54:28 |
Message-ID: | 200904112054.n3BKsS121627@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> A thread over in -admin has made me realize the truth of $SUBJECT.
> With --clean, pg_dumpall does indeed emit a DROP command for each
> role, tablespace, or database ... just before recreating it. This
> takes no account of dependencies and so the role and tablespace
> drops are pretty much guaranteed to fail due to databases still
> depending on them.
>
> I'm not sure if we need any real dependency analysis. It seems
> like it would be sufficient to issue the drops in a separate
> pass:
> - drop all the databases
> - drop all the tablespaces
> - drop all the roles
> - go on with creation
>
> The roles might still have references to each other in step 3,
> but the DROP ROLE docs claim that's okay (I haven't tested).
Does your recently-applied patch address any of these TODO items?
Stop dumping CASCADE on DROP TYPE commands in clean mode
Allow pg_dump --clean to drop roles that own objects or
have privileges
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2009-04-11 21:09:03 | Re: change oid of a pg_type |
Previous Message | Alvaro Herrera | 2009-04-11 20:53:46 | Re: change oid of a pg_type |