Thread: pg_upgrade 9.6->9.6: column "amtype" does not exist
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 amhandlerFROM pg_am 'FEHLER...' translates to 'ERROR: Column "amtype" does not exist'. Christoph
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
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" --port5433 --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 amhandlerFROM 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
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
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 +