Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces
Date: 2011-10-19 21:49:44
Message-ID: CA+Tgmobsuj93emnu55myzFhGAV1GxVjWb_WOZ_cgOFma7rjoNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>> We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with lines like these:
>
>>     ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
>>     ALTER ROLE dude SET default_tablespace TO 'users';
>
> I'm beginning to think that the correct solution to these problems is to
> greatly restrict what you can set in ALTER ROLE/DATABASE SET.  Or at
> least to document that if you use it, you get to keep both pieces after
> you break pg_dump.

This is another instance of the general principle that we need to
create all the objects first, and then set their properties. I
believe you came up with one counterexample where we needed to set the
GUC first in order to be able to create the object, but ISTM most of
them are going the other way.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-10-19 21:52:24 Re: [v9.2] Fix Leaky View Problem
Previous Message Kevin Grittner 2011-10-19 21:29:39 Re: SSI implementation question