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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers