We have repeatedly tried to upgrade Portal 10.9.1 to 11.2 with no luck. We've opened a support ticket with no solution as of yet.
The process:
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for user-defined encoding conversions ok
Checking for user-defined postfix operators ok
Checking for incompatible polymorphic functions ok
Creating dump of global objects ok
Creating dump of database schemas
gwdb
postgres
template1
ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.
Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows in the new cluster ok
Deleting files from new pg_xact ok
Copying old pg_xact to new server
*failure*
Consult the last few lines of "pg_upgrade_utility.log" for
the probable cause of the failure.
Failure, exiting
It appears that the copying failure is causing the issue of the incorrect user being used. Looks like it is defaulting to using the OS user when it later tries to start the DB.
Anyone seen this?
Solved! Go to Solution.
This is what ended up working for us:
The name of the portal admin and the windows users (ours is a domain account) had to match. Once we did that, we were able to upgrade with no issue.
I'm guessing you are currently attempting to upgrade portal while logged in to the machine as !arcgis user.
My best guess is that the postgres upgrade is issuing pg_upgrade commands in a manner that doesn't explicitly specify a user, meaning it will simply try to use the current logged in user. Upon initial install of Portal, the postgres installation would likely have done something similar and created a username based on the current logged in user in its database.
I can think of a few ways to get around your current issue, but only the first in the below list may be considered supported.
I would say option number 1 is your best bet without Support guidance. Support may not endorse the other 2 options.
Timo
We are doing #1, this is the only user on that box (essentially)
I'm not sure about 2 and 3, but it's really looking like the Transaction log upgrade is failing
Copying old pg_xact to new server
I had a thought about this. It's a total guess. Did anything change with your default Portal Database admin account? Could the password have changed? Maybe try going into the Portal Administrator and resetting the database account password and retry the upgrade.
PortalAdmin --> home --> System--> Database--> Update Admin Account
We have never changed the Portal DB Admin, but this may be worth a try
Our system admin was able to find another clue from the upgrade log:
pg_upgrade_utility.log from d:\arcgisportal\temp
command: xcopy /e /y /q /r "D:/arcgisportal/db1709936077740/pg_xact" "D:/arcgisportal/db/pg_xact\" >> "pg_upgrade_utility.log" 2>&1
Invalid drive specification
0 File(s) copied
This may be the root of the problem.
Still don't know how to fix it...
We ran into the same issue with 10.9.1 to 11.1.
Have you managed to achieve any progress on this topic (Invalid drive specification)?
We haven't yet. We have escalated with ESRI, hoping to hear back soon.
We just encountered the same error from 10.9.1 to 11.2. Funny thing is the last attempt we don’t have this issue but we have a different issue about the indexer
Running into similar issue, any update on resolution? What did Esri Support recommend?