Re: pg_upgrade and wraparound
От | Adrian Klaver |
---|---|
Тема | Re: pg_upgrade and wraparound |
Дата | |
Msg-id | 29e163a5-3585-5d27-6f3d-e4cfe812b3ec@aklaver.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade and wraparound (Alexander Shutyaev <shutyaev@gmail.com>) |
Список | pgsql-general |
On 06/10/2018 11:46 PM, Alexander Shutyaev wrote: > >> Is this the regular Postgres log or the pg_upgrade log which should > be something like pg_upgrade_server.log? > > This is the pg_upgrade_dump_16400.log. > >>> How did you get into the 10 cluster to report on the database OID's and > names? > > After the pg_upgrade failed I was able to start both clusters, so I > connected to the new 10.4 cluster and ran the query. I am at a loss for an explanation. My thoughts: 1) The database with an OID of 0 is a mystery, though it does not seem to be stopping the upgrade by itself. 2) The upgrade stops because of transaction ID wraparound, which is strange as that is not showing up in the 9.6 cluster I presume. You might want the queries found below on the 9.6 and 10 clusters to help figure this out: https://www.postgresql.org/docs/10/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND SELECT c.oid::regclass as table_name, greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age FROM pg_class c LEFT JOIN pg_class t ON c.reltoastrelid = t.oid WHERE c.relkind IN ('r', 'm'); SELECT datname, age(datfrozenxid) FROM pg_database; > >>> Which database has the large objects? > > bof (OID=16400). It is also effectively the only database that matters > here. The other one - sslentry only contains a couple of tables and a > dozen of records. > >>> Did you check this view to confirm? > > Yes, I did: > > select * from pg_prepared_xacts; > transaction | gid | prepared | owner | database > -------------+-----+----------+-------+---------- > (0 rows) > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: