Robert Haas wrote: > On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian <br...@momjian.us> wrote: > > Robert Haas wrote: > >> action. ?I understand that failing is probably less code, but IMHO one > >> of the biggest problems with pg_upgrade is that it's too fragile: > >> there are too many seemingly innocent things that can make it croak > >> (which isn't good, when you consider that anyone using pg_upgrade is > >> probably in a hurry to get the upgrade done and the database back > >> on-line). ?It seems like this is an opportunity to get rid of one of > >> those unnecessary failure cases. > > > > FYI, the original design goal of pg_upgrade was to be do reliable > > upgrades and fail at the hint of any inconsistency. ?Seems it is time to > > adjust its goals. > > We definitely don't want it to do anything that could compromise data > integrity. But in this case there seems no risk of that, so it seems > we can have our cake and eat it, too.
Agreed. I was extra cautious. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
