pg_upgrade 9.6->9.6: column "amtype" does not exist

On Fri, Apr 1, 2016 at 2:31 PM, Christoph Berg <myon@debian.org> wrote:

I'm not sure this is a bug, but before it bites back too late, I'm
reporting it now.

This must be a regression from the changes made to the pg_am interface
by commit 65c5fcd353a859da9e61bfb2b92a99f12937de3b.

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Christoph Berg wrote:

Hi,

I'm not sure this is a bug, but before it bites back too late, I'm
reporting it now.

On pg_upgrading my catversion 201603111 9.6 cluster to 201603301, I
got the following error:

-----------------------------------------------------------------
pg_upgrade run on Fri Apr 1 22:50:07 2016
-----------------------------------------------------------------

Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Creating dump of global objects ok
Creating dump of database schemas

*failure*
Consult the last few lines of "pg_upgrade_dump_13007.log" for
the probable cause of the failure.

command: "/usr/lib/postgresql/9.6/bin/pg_dump" --host "/var/log/postgresql/pg_upgradecluster-9.6-9.6-main.lLkW" --port 5433 --username "postgres" --schema-only --quote-all-identifiers --binary-upgrade --format=custom --file="pg_upgrade_dump_13007.custom" "postgres" >> "pg_upgrade_dump_13007.log" 2>&1
pg_dump: [Archivierer (DB)] Anfrage fehlgeschlagen: FEHLER: Spalte „amtype“ existiert nicht
ZEILE 1: SELECT tableoid, oid, amname, amtype, amhandler::pg_catalog....
^
TIP: Perhaps you meant to reference the column "pg_am.amname".
pg_dump: [Archivierer (DB)] Anfrage war: SELECT tableoid, oid, amname, amtype, amhandler::pg_catalog.regproc AS amhandler FROM pg_am

The reason for the failure is that pg_dump knows that 9.6 installations
have the amtype column -- but on your older devel 9.6 install, it
doesn't exist. To fix it we would have to compare catalog versions in
pg_dump rather than major version, but we don't that anywhere. Anyway
many upgrades could fail depending on other patches because of the same
reason. I don't think we need to fix this.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

The reason for the failure is that pg_dump knows that 9.6 installations
have the amtype column -- but on your older devel 9.6 install, it
doesn't exist. To fix it we would have to compare catalog versions in
pg_dump rather than major version, but we don't that anywhere. Anyway
many upgrades could fail depending on other patches because of the same
reason. I don't think we need to fix this.

We've never expected pg_dump to be able to handle intermediate development
versions. It's enough of a maintenance burden that it knows how to dump
from all previous stable branches.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Apr 1, 2016 at 05:55:58PM -0400, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

The reason for the failure is that pg_dump knows that 9.6 installations
have the amtype column -- but on your older devel 9.6 install, it
doesn't exist. To fix it we would have to compare catalog versions in
pg_dump rather than major version, but we don't that anywhere. Anyway
many upgrades could fail depending on other patches because of the same
reason. I don't think we need to fix this.

We've never expected pg_dump to be able to handle intermediate development
versions. It's enough of a maintenance burden that it knows how to dump
from all previous stable branches.

Pg_upgrade does handle catalog version changes. I don't think we ever
anticipated catalog changes that would throw errors in pg_dump, which
pg_upgrade relies on. I am saying that someday we might need pg_dump to
track catalog versions. However, I am not even sure how pg_dump would
check the catalog version.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers