On Sat, Jun 22, 2013 at 3:55 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> 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.
We probably do need to preserve attribute numbers across an upgrade,
even for foreign tables. I think those could make their way into
other places. Consider:
rhaas=# create foreign data wrapper dummy;
CREATE FOREIGN DATA WRAPPER
rhaas=# create server s1 foreign data wrapper dummy;
CREATE SERVER
rhaas=# create foreign table ft1 (a int, b text) server s1;
CREATE FOREIGN TABLE
rhaas=# create table sam (x ft1);
CREATE TABLE
If the new and old clusters don't agree on the attribute numbers for
ft1, post-upgrade attempts to access sam.x will likely crash the
server.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
