From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: -Wformat-zero-length |
Date: | 2012-08-09 13:20:23 |
Message-ID: | CA+TgmoYwS1e39khowehzgv8P4f+DKARWabP8C4FfSeF9hkV7MA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 8, 2012 at 7:04 PM, Bruce Momjian <bruce(at)momjian(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-08-09 14:00:51 | Re: -Wformat-zero-length |
Previous Message | Amit Kapila | 2012-08-09 13:10:40 | Re: [WIP] Performance Improvement by reducing WAL for Update Operation |