On Sat, Jun 22, 2013 at 3:55 PM, Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
