On 06/20/2013 11:16 AM, I wrote:
>
> On 06/20/2013 10:43 AM, Robert Haas wrote:
>> On Tue, Jun 18, 2013 at 12:18 PM, Andrew Dunstan
>> <andrew@dunslane.net> wrote:
>>> As I was updating my cross version upgrade tester to include support
>>> for the
>>> 9.3 branch, I noted this dump difference between the dump of the
>>> original
>>> 9.3 database and the dump of the converted database, which looks
>>> odd. Is it
>>> correct?
>> It looks sketchy to me, but I'm not sure exactly what you're comparing.
>
>
> Essentially, cross version upgrade testing runs pg_dumpall from the
> new version on the old cluster, runs pg_upgrade, and then runs
> pg_dumpall on the upgraded cluster, and compares the two outputs. This
> is what we get when the new version is HEAD and the old version is 9.3.
>
> The reason this hasn't been caught by the standard same-version
> upgrade tests is that this module uses a more extensive cluster, which
> has had not only the core regression tests run but also all the
> contrib and pl regression tests, and this problem seems to be exposed
> by the postgres_fdw tests.
>
> At first glance to me like pg_dump in binary-upgrade mode is not
> suppressing something that it should be suppressing.
>
Yeah, after examination I don't see why we should output anything for
dropped columns of a foreign table in binary upgrade mode. This looks to
me like it's been a bug back to 9.1 where we introduced foreign tables.
I think something like the attached should fix it, although I'm not sure
if that's the right place for the fix.
cheers
andrew