On Mon, Oct 10, 2011 at 12:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I don't really
>> understand why it's not OK to just have pg_dump issue RESET ROLE at
>> appropriate points in the process; that seems like it would be
>> sufficient and not particularly ugly.
>
> Well, it was alleged that that would fix this problem:
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg00916.php
> but if it does fix it, I think that's a bug in itself:
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01031.php
Hmm.
> But more to the point, I think the specific case of "ALTER DATABASE SET
> ROLE" is just one element of a class of problems, namely that settings
> attached to either databases or roles could create issues for restoring
> a dump. Issuing RESET ROLE would fix only that one single case.
It's not very clear to me that we're going to find a fix that reaches
across every setting, though. I mean, for something like
maintenance_work_mem, there's no correctness issue regardless of when
the new setting takes effect, but there might very well be a
performance issue, and it's not really all that clear when the "right"
time to put the old setting back is. And that ambiguity about what's
actually correct is, perhaps, the root of the problem.
There are related cases where we have a clear-cut policy. For
example, we are clear that you must use the newer pg_dump against the
older server for best results. That's not always convenient, but at
least it's a line in the sand.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
