On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian <bruce@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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company