Select to view content in your preferred language

Portal 10.9.1 to 11.2 Upgrade Postgres Failure

3305
20
Jump to solution
03-05-2024 10:51 AM
RandyBonds_Jr_
Frequent Contributor

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:

  1. We take a backup
  2. We run the 11.2 setup, when prompted for the Windows Service Account, it is grayed out with what is the portal is currently running at (our_domain\!arcgis). We enter the password, etc, and everything is great.
  3. When on the next upgrade step (the web based part), the PostgreSQL upgrade fails, we see two items in the logs that seem to point to the issue:
    1. Copying old pg_xact to new server *failure* 
    2. FATAL: role "!arcgis" does not exist
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?

0 Kudos
20 Replies
RandyBonds_Jr_
Frequent Contributor

ESRI was less than helpful. Their next solution is to migrate to a fresh 10.9.1 Portal install on another machine and try again. We'll be doing the migration Monday, and then try the upgrade again within a few weeks.

0 Kudos
QiranLiang
Regular Contributor

try resetting your portal database admin account, that fixes the issue for us. 

0 Kudos
VerstraetenTim
New Contributor

Hi, I seem to have the same issue. Can I ask to which db admin account you have resetted? the default postgres one, the one for the technical user running the ArcSOC process, the username for the portal admin,...? 

0 Kudos
Dan_Brumm
Frequent Contributor

Goto the Portaladmin --> System --> Database.  

Daniel Brumm
GIS Nerd
0 Kudos
VerstraetenTim
New Contributor

I tried changing it. I guess it changed the user (even though the user interface on portaladmin throws an error). I was hoping to set it to the same user as the technical account running the installation, but unfortunately that password contains special characters 🙃

0 Kudos
CraigSwadner
Regular Contributor

We have tried several times as well from 10.9.1 to 11.2 and our upgrade fails.  

0 Kudos
sahook1
Emerging Contributor

Hi @CraigSwadner ,

How did you solved this issue?

can you please post here.

0 Kudos
JérômeSautier
Esri Contributor

Hi @RandyBonds_Jr_ and @CraigSwadner 
I'm a bit late to the topic. But we just had a similiar behavior at an Upgrade from 10.8.1 to 11.3.
We had to install Visual C++ (64bit) Redistributable for 2013 to make it work. Without it the postgresql database in the background could not start and start the upgrade.
Cheers
Jerome

0 Kudos
RandyBonds_Jr_
Frequent Contributor

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.

sahook1
Emerging Contributor

Hi Team,

Any other work around without matching the portal admin account with service account?

I have similar issue while upgrading from 10.8.1 to 10.9.1 and the services are not starting after the upgrade.

0 Kudos