Re: "column i.indnkeyatts does not exist" in pg_upgrade from 11devto 11b1
От | Justin Pryzby |
---|---|
Тема | Re: "column i.indnkeyatts does not exist" in pg_upgrade from 11devto 11b1 |
Дата | |
Msg-id | 20180529190849.GA989@telsasoft.com обсуждение исходный текст |
Ответ на | Re: "column i.indnkeyatts does not exist" in pg_upgrade from 11dev to 11b1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "column i.indnkeyatts does not exist" in pg_upgrade from 11dev to 11b1
|
Список | pgsql-hackers |
On Tue, May 29, 2018 at 02:00:20PM -0400, Tom Lane wrote: > Justin Pryzby <pryzby@telsasoft.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
В списке pgsql-hackers по дате отправления: