On Thu, Aug 9, 2012 at 09:20:23AM -0400, Robert Haas wrote: > On Wed, Aug 8, 2012 at 7:04 PM, Bruce Momjian <br...@momjian.us> wrote: > >> The point I think Robert was trying to make is that we need to cut down > >> not only the complexity of running pg_upgrade, but the number of failure > >> modes. At least that's how I'd define improvement here. > > > > Agreed. Even with these changes, I still see a lot of complexity. > > I agree. That's why I said it needs some serious engineering time to > file down the rough edges, plural, not that it needs this fix in > particular. This would help to make things less error-prone, but it's > far from the only thing that is needed. As to what exactly is needed, > well that's up for discussion. > > One of the big failure modes for pg_upgrade is... pg_dump's dump fails > to restore. That bothers me quite a bit because there are actually a > lot more people who rely on pg_dump than there are people who rely on > pg_upgrade, and it turns out there are all of these edge cases that > pg_dump doesn't actually handle all that well. Sure, you can edit the > dump by hand (if you're not using pg_upgrade) but that sucks.
100% agree. 9.2 will improve pg_upgrade debugging capabilities and speed, but there are still many rough edges where that I don't see clear solutions. Therefore, I don't see pg_upgrade being simple anytime soon, and hence, it is also unlikely pg_upgrade will be moved to /bin anytime soon, if we use the same criteria. -- 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
