On Fri, Nov 29, 2013 at 12:46:01AM +0100, Karsten Hilbert wrote:
> On Thu, Nov 28, 2013 at 10:39:18AM -0500, Bruce Momjian wrote:
>
> > Well, then we are actually using two different reasons for patching
> > pg_dumpall and not pg_dump. Your reason is based on the probability of
> > failure, while Tom/Kevin's reason is that default_transaction_read_only
> > might be used to block changes to a specific database, and they want a
> > pg_dump restore prevented, but a pg_dumpall restore to succeed.
>
> I can't really argue one way or another because *I* am
> not likely to be able to offer an actual patch. At any
> rate all I am interested in is that pg_upgrade does not
> fail to upgrade in surprising ways.
Once the patch is applied, I will be patching pg_upgrade by appending to
PGOPTIONS, but that will only be for 9.4. The patch will be too risky
and there are not enough problem reports to override that and warrant
backpatching.
> Regarding restoring a pg_dump IMO the line would need to
> be drawn along the -c/--clean option because using such seems
> to clearly say that, yes, the user *wants* data to be deleted.
>
> If -C/--create is used it shouldn't matter ...
>
> However, I'm not saying that this is how it is to
> be done. I am well aware that drawing such subtle
> distinctions is walking quite a fine line.
So you are saying that default_transaction_read_only should be turned
off by pg_dump if --clean is used? Interesting.
The bottom line is that we can't handle every case and if we tried the
code would be very complex and error-prone. I am not sure where to draw
the line but it has to be drawn somewhere.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
