13.10 --> 13.20: Call to pg_dumpall returned 1

Installation Forum (Inactive)
13.10 --> 13.20: Call to pg_dumpall returned 1 trent  2014-03-11 21:41
Status: Closed
 
Hi,

We seem to be running into an issue with the graphical installer upgrade. The System admin was trying to use the 13.30 installer and got the error, but I just tried with 13.20 to rule out a non-incremental upgrade being the issue - but am getting the same result.

I think these are the relevant lines from install.log:

Exec: command="net start LabKey_pgsql-9.2"
Exec: success ("net start LabKey_pgsql-9.2")
Exec: command=""C:\Program Files\LabKey Server\Postgres9.2\bin\pg_dumpall.exe" -f "C:\Program Files\LabKey Server\upgrade_backup\labkey.dump" --username=sa -p 5432 -o"
Exec: success (""C:\Program Files\LabKey Server\Postgres9.2\bin\pg_dumpall.exe" -f "C:\Program Files\LabKey Server\upgrade_backup\labkey.dump" --username=sa -p 5432 -o")
detailprint: Call to pg_dumpall returned 1
MessageBox: 16,"Upgrade failed: Unable to dump LabKey Postgres database
The installer will now exit. Your LabKey instance should be intact."
Call: 6596

However, if I open command prompt and run that command, it works without any issue.

Any tips?

Log's attached if of any help.

When I ran for a 2nd time, it didnt recover from a failed installation and had different errors. (Probably wont be recovered until Friday)

Exec: command="net stop LabKey_pgsql-9.2"

Exec: success ("net stop LabKey_pgsql-9.2")

detailprint: Call to stop LabKey_pgsql-9.2 returned 0

detailprint: Waiting for Postgres to stop ...

Sleep(2000)

Exec: command=""C:\Program Files\LabKey Server\3rdparty\postgres\postgresql-9.2.4-1-windows.exe" --mode unattended --unattendedmodeui minimal --servicename "LabKey_pgsql-9.2" --superaccount sa --superpassword "sa" --prefix "C:\Program Files\LabKey Server\Postgres9.2" --datadir "C:\Program Files\LabKey Server\Postgres9.2\data" --serverport 5432 --create_shortcuts 0"

Exec: success (""C:\Program Files\LabKey Server\3rdparty\postgres\postgresql-9.2.4-1-windows.exe" --mode unattended --unattendedmodeui minimal --servicename "LabKey_pgsql-9.2" --superaccount sa --superpassword "sa" --prefix "C:\Program Files\LabKey Server\Postgres9.2" --datadir "C:\Program Files\LabKey Server\Postgres9.2\data" --serverport 5432 --create_shortcuts 0")

MessageBox: 48,"Postgres upgrade failed: 1


Log files attached
 
 
trent responded:  2014-03-16 23:13
What I did.

1. backup database use pg_dump
2. uninstall
3. install
4. restore
5. upgrade

If I went to upgrade again, I got the error as per OP, so I repeated this messy process until I got to 14.10. Any insight as to why pg_dumpall would stop working on upgrades (but working fine otherwise) would be greatly appreciated :-)
 
Trey responded:  2014-03-17 08:59
Postgres dump errors like this are usually caused by permissions problems. It's also possible that the installer is trying to do the dump too soon after starting postgres.
I have a few questions that might help me figure out what happened here.
What version/localization of Windows is this server running?
How powerful is the hardware running this server?
Can you provide the postgres install log from the failed postgres upgrade? (http://wiki.postgresql.org/wiki/Troubleshooting_Installation)
Is the username/password in this log accurate?
When you did the dump manually, did you have to enter a username & password?
What do you see in C:\Users\trent\AppData\Roaming\postgresql\?
 - If present, does pgpass.conf look like "localhost:5432:*:username:password"?
 - What about pgpass.conf.backup?
Did you make any manual changes to the server configuration - either Tomcat or Postgres?

Thanks,
Trey
 
trent responded:  2014-03-17 20:50
Hi Trey,

Version: Windows Server 08 Enterprise without Hyper-V
Hardware: 2.4Ghz Opteron; 4gb RAM

When doing the dump manually, I did *not* have to enter a password. I copied the command exactly as it was in the log file and without any more prompts it succeeded.

As per that document you linked, I can see a bunch of bitrock_installer logs from yesterday in the system temp folder, but after inspecting, nothing out of the ordinary.

Unfortunately, I don't still have any other logs from the failed attempts. I'll be upgrading another system in a couple of weeks so will be interesting to see if the problem persists on that environment (largely a cloned environment).

pgpass.conf is correct (I did previously check this out)

I haven't being doing previous upgrades, so I can't say for 100% sure if any server configurations were altered, but not that I'm aware.