>>
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.
>>
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)
2018-06-11 3:15 GMT+03:00 Adrian Klaver <adrian.klaver@xxxxxxxxxxx>:
On 06/10/2018 02:45 PM, Alexander Shutyaev wrote:
Comments inline.
The error log is like this. Here's its tail:
Is this the regular Postgres log or the pg_upgrade log which should be something like pg_upgrade_server.log?
pg_restore: [archiver (db)] could not execute query: ERROR: database is not accepting commands to avoid wraparound data loss in database with OID 0
HINT: Stop the postmaster and vacuum that database in single-user mode.
How did you get into the 10 cluster to report on the database OID's and names?
You might also need to commit or roll back old prepared transactions.
Command was: ALTER LARGE OBJECT 1740737402 OWNER TO bof_user;
Before that there is a lot of similar messages - the only things chainging are the "executing BLOB nnn" number and "must be vacuumed within nnn transactions" number.
Which database has the large objects?
As for the prepared transactions - no, I don't have them, our application doesn't use this functionality.
Did you check this view to confirm?:
https://www.postgresql.org/docs/10/static/view-pg-prepared- xacts.html
Just trying to eliminate possibilities.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
