Re: pg_upgrade and wraparound

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Alexander Shutyaev <shutyaev(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_upgrade and wraparound
Date: 2018-06-10 21:34:55
Message-ID: 8b14df48-20e9-3dd0-9990-7131f95bd30a@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 06/10/2018 02:09 PM, Alexander Shutyaev wrote:
> Some more notes on databses.
>
> Although the pg_upgrade failed, I've decided to check the databases in
> the new cluster (10.4). There is no database with oid 0 either. Also to
> be noted that some system databases changed the oids while others
> retained them.

If I am following the source code for pg_upgrade correctly that is
expected. Pretty sure because the order of object creation is different.

>
> And of my databases - sslentry. It had a very big oid (can that seem
> strange?) and its oid has changed.

OID's are added at time of object creation so I would say the ssslentry
database was created some time after the other databases in the 9.6
cluster. Actually probably more accurate to say after 1016305714 -
16400(bof db) objects that have OID's where created.

When the upgrade failed pg_upgrade should have pointed you at an error log.

Did it and is there anything useful there?

From your OP post:

"You might also need to commit or roll back old prepared transactions."

Do you have any of those in the 9.6 cluster?

See:

https://www.postgresql.org/docs/10/static/view-pg-prepared-xacts.html

>
> select oid, datname from pg_database;
>   oid  |  datname
> -------+-----------
>  13011 | template0
>  16400 | bof
>  13012 | postgres
>  16401 | sslentry
>      1 | template1
> (5 rows)
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alexander Shutyaev 2018-06-10 21:45:41 Re: pg_upgrade and wraparound
Previous Message Alexander Shutyaev 2018-06-10 21:09:19 Re: pg_upgrade and wraparound