Thanks for your explanation. Just one more clarification. See below

On Fri, Aug 3, 2018 at 5:06 PM, Jan Siml <jsiml@plusline.net> wrote:
Hello,

So your workflow was:

- run engine-setup and got failure
was it able in your case to restore the engine db in this first run and start engine again?
You wrote that there was an upload failure and that you removed it: did you mean you removed it from the GUI, and confirming that after first failure the webadmin gui was still reachable?

 No, WUI was down because service was stopped by engine-setup and not started afterwards when restore of DB backups failed. But starting ovirt-engine service brought engine and WUI up.

Can you confirm if also in your case the rollback of the db failed? If so, how could you be sure of the consistency of the database if only a partial restore has been executed and the pg_restore command failed?
So after manually starting the engine service you were able to connect and delete from GUI the transfer, correct?
 


- run engine-setup again and got failure
It seems that after this second failure your engine and dwh db are down, so also the engine portal...
Then you manually execute the delete statement

- engine-setup again and it succeeds

Correct?

 Yes, just inspected the table, deleted one row with the mentioned stament and sucessfully retried the upgrade.

Regards

Jan

So after the GUI deletion of the wrong transfer you executed engine-setup again; did you choose to backup the db or not when proposed? 
after the error you manually deleted and executed again engine-setup

So at the end you run 3 times the engine-setup program?

It remains my doubt about the status of the engine database due to pg_restore failed in the middle, so some tables/objects could have the old structure and some tables the new.
It should be analyzed in your case from 4.2.4 to 4.2.5 what are the db operation to execute duting upgrade and in my case  when trying to pass from 4.2.3 to 4.2.5

Gianluca