Re: pg_upgrade and wraparound - Mailing list pgsql-general

From Adrian Klaver
Subject Re: pg_upgrade and wraparound
Date
Msg-id 107c7c17-2e53-6cd1-1dbd-94d63f7a205f@aklaver.com
Whole thread Raw
In response to pg_upgrade and wraparound  (Alexander Shutyaev <shutyaev@gmail.com>)
Responses Re: pg_upgrade and wraparound  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 06/09/2018 03:46 AM, Alexander Shutyaev wrote:
> Hello!
> 
> I've been trying to upgrade a postgresql cluster from 9.6 to 10. I've 
> executed the pg_upgrade with the following options:
> 
>   /usr/lib/postgresql/10/bin/pg_upgrade -b /usr/lib/postgresql/9.6/bin/ 
> -B /usr/lib/postgresql/10/bin/ -d /var/lib/postgresql/9.6/main -D 
> /var/lib/postgresql/10/main -o ' -c 
> config_file=/etc/postgresql/9.6/main/postgresql.conf' -O ' -c 
> config_file=/etc/postgresql/10/main/postgresql.conf'
> 
> The upgrade operation failed after several hours with the following error:
> 
> database is not accepting commands to avoid wraparound data loss in 
> database with OID 0

Do you know which database has an OID of 0?

> 
> Earlier in the log there are a lot of messages like
> 
> pg_restore: executing BLOB 1740736966
> pg_restore: WARNING:  database with OID 0 must be vacuumed within 
> 1000279 transactions
> HINT:  To avoid a database shutdown, execute a database-wide VACUUM in 
> that database.
> You might also need to commit or roll back old prepared transactions.
> pg_restore: WARNING:  database with OID 0 must be vacuumed within 
> 1000278 transactions
> HINT:  To avoid a database shutdown, execute a database-wide VACUUM in 
> that database.
> You might also need to commit or roll back old prepared transactions.
> 
> I've tried to do VACUUM FULL on my 9.6 cluster on all databases and then 
> retried the pg_upgrade - it failed in the same way.
> 
> Also to be noted, earlier this cluster was succesfully upgraded with 
> pg_upgrade using similar parameters from older versions (at least 2 
> times, something like 9.1 -> 9.3, 9.3 -> 9.6). The database is around 
> 700 GB and has very many pg_largeobjects in it.
> 
> What could be the reason of this and how can I perform my upgrade?
> 
> Thanks in advance,
> Alexander


-- 
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Maksim Milyutin
Date:
Subject: Re: Slow planning time for simple query
Next
From: Tom Lane
Date:
Subject: Re: Slow planning time for simple query