From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "column i.indnkeyatts does not exist" in pg_upgrade from 11dev to 11b1 |
Date: | 2018-05-29 19:08:49 |
Message-ID: | 20180529190849.GA989@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 29, 2018 at 02:00:20PM -0400, Tom Lane wrote:
> Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> > I've used pg_upgrade like this before, but maybe from a different (recent)
> > 11dev HEAD; I found: "pg_upgrade supports upgrades from 8.4.X and later to the
> > current major release of PostgreSQL, including snapshot and beta releases."
> > (But maybe upgrades FROM beta releases aren't supported in the general case?)
>
> Yeah, that :-(. pg_dump's approach to cross-version catalog differences
> can only cope with differences between major versions. So if it sees
> a server that calls itself 11-something it's going to think that means
> the current catalog layout. There's no good way to deal with pre-beta
> snapshot versions, other than to dump with a pg_dump of the same vintage.
Thanks for confirming.
In this case I worked around it by doing:
sudo ln -sfv /usr/pgsql-11{dev0,b1}/bin/pg_dump
sudo ln -sfv /usr/pgsql-11{dev0,b1}/bin/pg_dumpall
I guess, if need be, pg_dump could look at CATALOG_VERSION..
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-05-29 19:21:00 | Re: behave of --create-slot option |
Previous Message | Christoph Berg | 2018-05-29 18:49:49 | Re: plperl fails with perl 5.28 |