Re: Upgrading to v12

Поиск
Список
Период
Сортировка
От Ron
Тема Re: Upgrading to v12
Дата
Msg-id 5bdec7a2-bfec-b0f3-2e23-09ea7c9303cf@gmail.com
обсуждение исходный текст
Ответ на Re: Upgrading to v12  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: Upgrading to v12  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On 11/11/22 23:09, Adrian Klaver wrote:
On 11/11/22 20:59, Brad White wrote:
On Fri, Nov 11, 2022, 9:57 PM Adrian Klaver <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote:

Yes. The backup is from production.
V9.4 is running on 5432 on all servers.
That particular restore happens to be on the dev server. 5433 is v12.


1) This does not address from your OP:

"I only need the primary.
Not the half dozen restored copies."

And then from follow up post:

"I deleted all the other DBs and left only the primary.
Still getting the same error message, ending with"

How where the restored copies made on the original cluster?

2) For your explanation above, pg_dump from 9.4(5432) to pg_restore 12(5433) the issue would be ...\9.4\bin\pg_dump.exe of 9.4 and pg_restore of said dump file to version 12. When moving up in version you need to use the newer version of pg_dump(...\12\bin\pg_dump.exe) to dump the 9.4 instance and then the version 12 pg_restore to the 12 instance. Both programs are backwards compatible, not forwards compatible.

Unless there's some bug (you're running a really old version of 9.4), you might be able to get away with using the 9.4 binary.  (I successfully migrated 8.4.17 to 9.6.6 and  9.2.7 databases to 9.6.24, and 9.6.24 databases to 13.8 using the old pg_dump binaries when it was impractical to install the newer Postgresql in parallel with the old binaries.)

--
Angular momentum makes the world go 'round.

В списке pgsql-general по дате отправления:

Предыдущее
От: Brad White
Дата:
Сообщение: Re: Upgrading to v12
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Upgrading to v12