Обсуждение: pg_upgrade 9.6 to 12 without 9.6 binaries

Поиск
Список
Период
Сортировка

pg_upgrade 9.6 to 12 without 9.6 binaries

От
"Zwettler Markus (OIZ)"
Дата:

We are running Postgres 9.6 on server A.

 

We want to upgrade it to Postgres 12 on server B.

 

pg_upgrade requires the old (-b) and new (-B) binary set on the same server.

 

We don't want to install both binary sets on the same server as we had some library conflicts in the past.

 

Is there still a way to use pg_upgrade without the old (-b) binary set (I am aware of pg_dump/pg_restore)?

 

Markus

 

 

 

 

Re: pg_upgrade 9.6 to 12 without 9.6 binaries

От
Adrian Klaver
Дата:
On 3/13/20 6:47 AM, Zwettler Markus (OIZ) wrote:
> We are running Postgres 9.6 on server A.
> 
> We want to upgrade it to Postgres 12 on server B.
> 
> pg_upgrade requires the old (-b) and new (-B) binary set on the same server.
> 
> We don't want to install both binary sets on the same server as we had 
> some library conflicts in the past.
> 
> Is there still a way to use pg_upgrade without the old (-b) binary set 
> (I am aware of pg_dump/pg_restore)?

No. As I understand it pg_upgrade needs to see the state of old instance 
to recreate that state on the new instance.

> 
> Markus
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



Re: pg_upgrade 9.6 to 12 without 9.6 binaries

От
Jerry Sievers
Дата:
Adrian Klaver <adrian.klaver@aklaver.com> writes:

> On 3/13/20 6:47 AM, Zwettler Markus (OIZ) wrote:
>
>> We are running Postgres 9.6 on server A.
>>
>> We want to upgrade it to Postgres 12 on server B.
>>
>> pg_upgrade requires the old (-b) and new (-B) binary set on the same server.
>>
>> We don't want to install both binary sets on the same server as we
>> had some library conflicts in the past.
>>
>> Is there still a way to use pg_upgrade without the old (-b) binary
>> set (I am aware of pg_dump/pg_restore)?
>
> No. As I understand it pg_upgrade needs to see the state of old
> instance to recreate that state on the new instance.

True.

PgUpgrade will start/stop both versions separately perhaps a couple of
times as part of the workflow.

>
>>
>> Markus
>>

-- 
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net