Schema upgrade error while updating 4.2.4 to 4.2.5
Hello, I stumbled across the following bug when upgrading the ovirt engine from 4.2.4 to 4.2.5 (snippet from upgrade log): Running upgrade sql script '/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql'... 2018-08-02 09:14:33,116+0200 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u' , 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20180802091038-xclfnu.log', '-c', 'apply'] stderr: psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql:1: ERROR: insert or update on table "image_transfers" violates foreign key constraint "fk_image_transfers_command _enitites" DETAIL: Key (command_id)=(312f711f-a5c3-477d-8533-82ef88a54b77) is not present in table "command_entities". FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql 2018-08-02 09:14:33,117+0200 ERROR otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:434 schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_12 10_add_foreign_key_to_image_transfers.sql 2018-08-02 09:14:33,119+0200 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", line 436, in _misc raise RuntimeError(_('Engine schema refresh failed')) RuntimeError: Engine schema refresh failed 2018-08-02 09:14:33,122+0200 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Engine schema refresh failed Are there already instructions on how to deal with this error and does anyone know why this error occurs? Kind regards Jan
We actually hit this internally too, so looks like a bug. @Eli Mesika <emesika@redhat.com> On Thu, Aug 2, 2018 at 4:17 AM Jan Siml <jsiml@plusline.net> wrote:
Hello,
I stumbled across the following bug when upgrading the ovirt engine from 4.2.4 to 4.2.5 (snippet from upgrade log):
Running upgrade sql script
'/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql'...
2018-08-02 09:14:33,116+0200 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u' , 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20180802091038-xclfnu.log',
'-c', 'apply'] stderr: psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql:1:
ERROR: insert or update on table "image_transfers" violates foreign key constraint "fk_image_transfers_command _enitites" DETAIL: Key (command_id)=(312f711f-a5c3-477d-8533-82ef88a54b77) is not present in table "command_entities". FATAL: Cannot execute sql command:
--file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql
2018-08-02 09:14:33,117+0200 ERROR otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:434 schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_12 10_add_foreign_key_to_image_transfers.sql 2018-08-02 09:14:33,119+0200 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
line 436, in _misc raise RuntimeError(_('Engine schema refresh failed')) RuntimeError: Engine schema refresh failed 2018-08-02 09:14:33,122+0200 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Engine schema refresh failed
Are there already instructions on how to deal with this error and does anyone know why this error occurs?
Kind regards
Jan _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/IHPQ2EQ52MVTVZ...
-- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme@redhat.com IRC: gshereme <https://red.ht/sig>
Hello, If there are Disk Uploads that have not completed (i.e: currently Paused or with Error) and were not canceled the upgrade will fail.This is due to a foreign key being added on 4.2.5, relating image_transfers table to command_entities table. When the roll-back to the previous RHV-M version finishes, open the Administration Portal and navigate to Storage -> Disks. Browse all disks looking for disks with status different than OK, such as Paused by System. Right click and cancel/remove these failed or paused uploads, then try the upgrade again. If it fails then share your observations with us, so we need to do some manual changes in database. Regards, Vaibhav Pagar
Hello,
If there are Disk Uploads that have not completed (i.e: currently Paused or with Error) and were not canceled the upgrade will fail.This is due to a foreign key being added on 4.2.5, relating image_transfers table to command_entities table.
When the roll-back to the previous RHV-M version finishes, open the Administration Portal and navigate to Storage -> Disks.
there was indeed one disk upload which wasn't finshed. I have canceled it and removed the disk.
If it fails then share your observations with us, so we need to do some manual changes in database. The seconds attempt to update failed to:
Running upgrade sql script '/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql'... 2018-08-03 12:45:05,808+0200 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20180803124017-k94hg1.log', '-c', 'apply'] stderr: psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql:1: ERROR: insert or update on table "image_transfers" violates foreign key constraint "fk_image_tran sfers_command_enitites" DETAIL: Key (command_id)=(312f711f-a5c3-477d-8533-82ef88a54b77) is not present in table "command_entities". FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql 2018-08-03 12:45:05,809+0200 ERROR otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:434 schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upg rade/04_02_1210_add_foreign_key_to_image_transfers.sql 2018-08-03 12:45:05,812+0200 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", line 436, in _misc raise RuntimeError(_('Engine schema refresh failed')) RuntimeError: Engine schema refresh failed 2018-08-03 12:45:05,815+0200 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Engine schema refresh failed The restore for both databases (engine and engine_hirory) fails too: pg_restore: [archiver (db)] Error from TOC entry 7339; 0 0 COMMENT EXTENSION "uuid-ossp" pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension uuid-ossp Regards Jan
On Fri, Aug 3, 2018 at 7:01 AM Jan Siml <jsiml@plusline.net> wrote:
Hello,
If there are Disk Uploads that have not completed (i.e: currently Paused or with Error) and were not canceled the upgrade will fail.This is due to a foreign key being added on 4.2.5, relating image_transfers table to command_entities table.
When the roll-back to the previous RHV-M version finishes, open the Administration Portal and navigate to Storage -> Disks.
there was indeed one disk upload which wasn't finshed. I have canceled it and removed the disk.
If it fails then share your observations with us, so we need to do some manual changes in database. The seconds attempt to update failed to:
Running upgrade sql script
'/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql'...
Turns out this is a regression that we are working urgently to fix: https://bugzilla.redhat.com/show_bug.cgi?id=1609839 Thanks to all who have reported!
2018-08-03 12:45:05,808+0200 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20180803124017-k94hg1.log',
'-c', 'apply'] stderr: psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql:1:
ERROR: insert or update on table "image_transfers" violates foreign key constraint "fk_image_tran sfers_command_enitites" DETAIL: Key (command_id)=(312f711f-a5c3-477d-8533-82ef88a54b77) is not present in table "command_entities". FATAL: Cannot execute sql command:
--file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql
2018-08-03 12:45:05,809+0200 ERROR otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:434 schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upg rade/04_02_1210_add_foreign_key_to_image_transfers.sql 2018-08-03 12:45:05,812+0200 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
line 436, in _misc raise RuntimeError(_('Engine schema refresh failed')) RuntimeError: Engine schema refresh failed 2018-08-03 12:45:05,815+0200 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Engine schema refresh failed
The restore for both databases (engine and engine_hirory) fails too:
pg_restore: [archiver (db)] Error from TOC entry 7339; 0 0 COMMENT EXTENSION "uuid-ossp" pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension uuid-ossp
Regards
Jan _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/DSVVDV42APPUKQ...
-- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme@redhat.com IRC: gshereme <https://red.ht/sig>
On Fri, Aug 3, 2018 at 2:01 PM Jan Siml <jsiml@plusline.net> wrote:
Hello,
If there are Disk Uploads that have not completed (i.e: currently Paused or with Error) and were not canceled the upgrade will fail.This is due to a foreign key being added on 4.2.5, relating image_transfers table to command_entities table.
When the roll-back to the previous RHV-M version finishes, open the Administration Portal and navigate to Storage -> Disks.
there was indeed one disk upload which wasn't finshed. I have canceled it and removed the disk.
If it fails then share your observations with us, so we need to do some manual changes in database. The seconds attempt to update failed to:
Running upgrade sql script
'/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql'...
2018-08-03 12:45:05,808+0200 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20180803124017-k94hg1.log',
'-c', 'apply'] stderr: psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql:1:
ERROR: insert or update on table "image_transfers" violates foreign key constraint "fk_image_tran sfers_command_enitites" DETAIL: Key (command_id)=(312f711f-a5c3-477d-8533-82ef88a54b77) is not present in table "command_entities". FATAL: Cannot execute sql command:
--file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql
There are probably some more stale image transfers records, can you please check whether 'image_transfers' table is empty? If not, you can try removing them by executing: "DELETE FROM image_transfers WHERE command_id NOT IN (SELECT command_entities.command_id FROM command_entities);" (you can simply prepend it to '04_02_1210_add_foreign_key_to_image_transfers.sql')
2018-08-03 12:45:05,809+0200 ERROR otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:434 schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upg rade/04_02_1210_add_foreign_key_to_image_transfers.sql 2018-08-03 12:45:05,812+0200 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
line 436, in _misc raise RuntimeError(_('Engine schema refresh failed')) RuntimeError: Engine schema refresh failed 2018-08-03 12:45:05,815+0200 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Engine schema refresh failed
The restore for both databases (engine and engine_hirory) fails too:
pg_restore: [archiver (db)] Error from TOC entry 7339; 0 0 COMMENT EXTENSION "uuid-ossp" pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension uuid-ossp
Regards
Jan _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/DSVVDV42APPUKQ...
Hello,
There are probably some more stale image transfers records, can you please check whether 'image_transfers' table is empty? If not, you can try removing them by executing: "DELETE FROM image_transfers WHERE command_id NOT IN (SELECT command_entities.command_id FROM command_entities);" (you can simply prepend it to '04_02_1210_add_foreign_key_to_image_transfers.sql')
that's how it worked and the update was successful. Thanks! Regards Jan
As the potential user could upgrade from an older version, though not recommended to stay too much below, I simulate this upgrade from 4.2.3.7 (current engine package version is ovirt-engine-4.2.3.7-1.el7.noarch updated on 26/05) to 4.2.5 and I get this in engine-setup [ INFO ] Backing up database localhost:engine to '/var/lib/ovirt-engine/backups/engine-20180803141347.gdQfiz.dump'. [ INFO ] Creating/refreshing Engine database schema [ ERROR ] schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_1210_add_foreign_key_to_image_transfers.sql [ ERROR ] Failed to execute stage 'Misc configuration': Engine schema refresh failed [ INFO ] Yum Performing yum transaction rollback [ INFO ] Restoring file '/var/lib/ovirt-engine/backups/engine-20180803141347.gdQfiz.dump' to database localhost:engine. [ ERROR ] Errors while restoring engine database, please check the log file for details [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20180803140934-1thg3k.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20180803141603-setup.conf' [WARNING] Rollback of DWH database started This might be a long process, but it should be safe to start the engine service before it finishes, if needed. [ INFO ] Clearing DWH database ovirt_engine_history [ INFO ] Restoring DWH database ovirt_engine_history [ INFO ] Restoring file '/var/lib/ovirt-engine-dwh/backups/dwh-20180803141340.cQoOU2.dump' to database localhost:ovirt_engine_history. [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed [root@ovirt ~]# Until fixed what would be the step to resolve, as also the restore of database failed? What can I do to restore/clean/upgrade again? BTW: it is a self hosted engine Thanks, Gianluca On Fri, Aug 3, 2018 at 2:14 PM, Jan Siml <jsiml@plusline.net> wrote:
Hello,
There are probably some more stale image transfers records,
can you please check whether 'image_transfers' table is empty? If not, you can try removing them by executing: "DELETE FROM image_transfers WHERE command_id NOT IN (SELECT command_entities.command_id FROM command_entities);" (you can simply prepend it to '04_02_1210_add_foreign_key_to _image_transfers.sql')
that's how it worked and the update was successful. Thanks!
Regards
Jan _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/communit y/about/community-guidelines/ List Archives: https://lists.ovirt.org/archiv es/list/users@ovirt.org/message/RQS4MHPWU7HWCZH6BIELHVGPB4BMBBGL/
In particular, the log of the db restore, where I can find it? to understand which state of the db I have now on disk... the old, the new, a partial restore or what... at this time the image_transfers table is clearly the old one without the foreign key: engine=# \d image_transfers Table "public.image_transfers" Column | Type | Modifiers ---------------------------+--------------------------+------------------------ command_id | uuid | not null command_type | integer | not null phase | integer | not null last_updated | timestamp with time zone | not null message | character varying | vds_id | uuid | disk_id | uuid | imaged_ticket_id | uuid | proxy_uri | character varying | signed_ticket | character varying | bytes_sent | bigint | bytes_total | bigint | type | integer | not null default 0 active | boolean | not null default false daemon_uri | character varying | client_inactivity_timeout | integer | Indexes: "pk_image_transfers" PRIMARY KEY, btree (command_id) "idx_image_transfers_disk_id" btree (disk_id) and contains engine=# select * from image_transfers; command_id | command_type | phase | last_updated | m essage | vds_id | disk_id | imaged _ticket_id | proxy_uri | signed_ticket | bytes_sent | bytes_total | type | active | daemon_uri | client_inactivity_timeout --------------------------------------+--------------+-------+----------------------------+------------ -----------------+--------------------------------------+--------------------------------------+------- -----------+--------------------------------+---------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------- ----------------------------------------------+------------+-------------+------+--------+------------+ --------------------------- 7b0e8a09-d8e9-48c4-83af-fdd94268f355 | 1024 | 6 | 2017-12-05 23:09:05.307+00 | Pausing due to client error | 459f6e56-f813-4c73-9950-994a7de8dbb5 | 713df8c6-8a97-425f-a169-fa2b7104bdc4 | | https://localhost:54323/images | eyJzYWx0IjoidHdLQWdwN0lnREU9IiwiZGF0YSI6IntcbiAgXCJuYmZcI iA6IDE1MTI1MTQ5NzIsXG4gIFwiZXhwXCIgOiAxNTEyNTE4NTcyLFxuICBcImlhdFwiIDogMTUxMjUxNDk3MixcbiAgXCJ0cmFuc2Zl ci10aWNrZXRcIiA6IFwiZTVjY2JiOWMtOTNlZS00MDRkLTgwOWItNDMzNzZkYTQ4ZmE3XCIsXG4gIFwiaW1hZ2VkLXVyaVwiIDogXCJ odHRwczovL292aXJ0MDEubHV0d3luLm9yZzo1NDMyMlwiXG59Iiwic2lnbmF0dXJlIjoibiszZ0pUbmgyd1gxYzUzMWNsRWwza1c1Mk 5vSEhXOGhUZGxZZmN1T3JURlVveHlicVhwaTZTRVhsWERCN2tOOXZBT1dMb1NhT0t5TTRWT1I0VTl1djNLdldHNHlTVUp1YWhha3dFY 3J3UUJkOTFwQVkrVXM1ZGRLRkxlSTB2NkQ2eitBOEJXRkduUkpNdCtxemJUeTd5dm5wTnVXSkxIMXlFOXFRTHFDWEN4UEZTSkNHekpY aTVveUZHQlNPTVNUdEtYbjVCS0gwejdGanR5akhZd3orMkRVM3Bxa0JESUp0dTZGRFZjeG9Gelp2bjR0amtla3M1WldvNS95NFYwekZ pcE5PdWJIZXNGMlpvL2liVGIrQ0pLZ0xyOFBHNzE1VmhKbmxlQ1BLbE5zV2VkcVRDSEE4M3ZxOHpjdFMveWZCZU9seEgzZ3BEZktkS0 tDYjlVcHNRPT0iLCJkaWdlc3QiOiJzaGExIiwiY2VydGlmaWNhdGUiOiItLS0tLUJFR0lOIENFUlRJRklDQVRFLS0tLS1cbk1JSUVjR ENDQTFpZ0F3SUJBZ0lDRUF3d0RRWUpLb1pJaHZjTkFRRUxCUUF3UXpFTE1Ba0dBMVVFQmhNQ1ZWTXhFekFSQmdOVkJBb1RcclxuQ214 MWRIZDViaTV2Y21jeEh6QWRCZ05WQkFNVEZtOTJhWEowTG14MWRIZDViaTV2Y21jdU16WTFPRGN3SGhjTk1UY3dPREkxTURneFxyXG5 NekF6V2hjTk1qSXdOek14TURneE16QXpXakE5TVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNoTUtiSFYwZDNsdUxtOXlaekVaXH Jcbk1CY0dBMVVFQXhNUWIzWnBjblF1YkhWMGQzbHVMbTl5WnpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnR UJcclxuQUxUM3JjQnhaOXU4Zk9EN3JzdWFXeE9CMDNucHZHVnpBU1lQeWtBRm54QVBsanpNK21xSlczWjlUcnJBb3I4Ujg4b3ZGNi9C K3QrUFxyXG5ic3BqZ1BGdGVNVWZ5ZDI2SEh1Wmw2bS9WSDg2MmlaS3owN1RNZndSZVF6bmNkYSt5dkhrWFNONEFEaXFVUmRhOFd0OEc 4MGlLUlVWXHJcbk00a2gvT3pUd0Zhd05ZZFhDcWVEckY4KzBFOFBWZFFNRG9vYnpxTjNTNWhCRDBJK291S284K0E5bkVlTzJxUW5KZ2 5OZHA1d25nTE1cclxuVFByRGhTUERQRS9WQ01FdnQ0WE5VcFJsVWswdlBWTm9wbmk1L0JUV0Z0RnFKNDRieWt4ejBDVE1lWGdZcDlYY npmNi8yY0oxdzV5a1xyXG5ydkZvTExPUnlXR1g1TTlKaENTbzdrWlRHSDFqeEtMMjFwY1JJVk1DQXdFQUFhT0NBWEl3Z2dGdU1CMEdB MVVkRGdRV0JCUXVjZGY2XHJcbkNlNXJuelpyeTVLYjhMcWFpRGJmN1RDQmhBWUlLd1lCQlFVSEFRRUVlREIyTUhRR0NDc0dBUVVGQnp BQ2htaG9kSFJ3T2k4dmIzWnBcclxuY25RdWJIVjBkM2x1TG05eVp6bzRNQzl2ZG1seWRDMWxibWRwYm1VdmMyVnlkbWxqWlhNdmNHdH BMWEpsYzI5MWNtTmxQM0psYzI5MVxyXG5jbU5sUFdOaExXTmxjblJwWm1sallYUmxKbVp2Y20xaGREMVlOVEE1TFZCRlRTMURRVEJzQ mdOVkhTTUVaVEJqZ0JTQWRjc3NPN3hrXHJcbnkwQkdtNCtibGJOaDlmWmduYUZIcEVVd1F6RUxNQWtHQTFVRUJoTUNWVk14RXpBUkJn TlZCQW9UQ214MWRIZDViaTV2Y21jeEh6QWRcclxuQmdOVkJBTVRGbTkyYVhKMExteDFkSGQ1Ymk1dmNtY3VNelkxT0RlQ0FoQUFNQWt HQTFVZEV3UUNNQUF3RGdZRFZSMFBBUUgvQkFRRFxyXG5BZ1dnTUNBR0ExVWRKUUVCL3dRV01CUUdDQ3NHQVFVRkJ3TUJCZ2dyQmdFRk JRY0RBakFiQmdOVkhSRUVGREFTZ2hCdmRtbHlkQzVzXHJcbmRYUjNlVzR1YjNKbk1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQVloT FJnb2h5dVE3SWRiaXhENTdlZDVJN1VINDFOTnFzK2M0SnVcclxuZXFiNG9XSGRtR1ZvWmR2dDBSTUNZRk4xU1p4YXRhMEcvSVFOUEtJ VW9QeHhXZ1Fod3FaUHhsQjcwMnZFdk1YNmZIdjdoTFBma1kyWlxyXG5yL2ZpLzZ4SE5GQU05dDE5K3h5SjRrTHhPc2ZpWkdKWjF6aHF 5UEFlT3l2VFJieUtiaHh6Y29STlRmL1p0cmZ2M0xWTHhQcDJnU1hFXHJcbnZ5MnN1V2t6YUZFd000RW4rTXNuajBhZ3Ixb0RRamNLRW twSjltc2pSMlJpb0xVVnRud3JpZU1XK2ljbnM0NjlpT3l1eWprY3M4a0lcclxuSkRGSXJ3aWg2MHJxVC9zSWlTSlAvQ2dXMGtYOU5Ra GlvT2kraXo2WHZYSjRmNjVpZm1jeTNlaEhMcGZ6NVdQVWx1UlB0Vy96Z3pxcFxyXG4tLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tXG4i LCJzaWduZWRGaWVsZHMiOiJzYWx0LGRhdGEsZGlnZXN0LHZhbGlkRnJvbSx2YWxpZFRvIiwidmFsaWRGcm9tIjoiMjAxNzEyMDUyMzA yNTIiLCJ2YWxpZFRvIjoiMjAxNzEyMDYwMDAyNTIifQ== | 0 | 21478375424 | 0 | f | | (1 row) engine=# can i simply delete the record and run again "engine-setup" or do "completely" roll back the db? Thanks, Gianluca On Fri, Aug 3, 2018 at 2:24 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
As the potential user could upgrade from an older version, though not recommended to stay too much below, I simulate this upgrade from 4.2.3.7 (current engine package version is ovirt-engine-4.2.3.7-1.el7.noarch updated on 26/05) to 4.2.5 and I get this in engine-setup
[ INFO ] Backing up database localhost:engine to '/var/lib/ovirt-engine/ backups/engine-20180803141347.gdQfiz.dump'. [ INFO ] Creating/refreshing Engine database schema [ ERROR ] schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_ 02_1210_add_foreign_key_to_image_transfers.sql [ ERROR ] Failed to execute stage 'Misc configuration': Engine schema refresh failed [ INFO ] Yum Performing yum transaction rollback
[ INFO ] Restoring file '/var/lib/ovirt-engine/ backups/engine-20180803141347.gdQfiz.dump' to database localhost:engine. [ ERROR ] Errors while restoring engine database, please check the log file for details [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ ovirt-engine-setup-20180803140934-1thg3k.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/ answers/20180803141603-setup.conf' [WARNING] Rollback of DWH database started This might be a long process, but it should be safe to start the engine service before it finishes, if needed. [ INFO ] Clearing DWH database ovirt_engine_history [ INFO ] Restoring DWH database ovirt_engine_history [ INFO ] Restoring file '/var/lib/ovirt-engine-dwh/ backups/dwh-20180803141340.cQoOU2.dump' to database localhost:ovirt_engine_history. [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed [root@ovirt ~]#
Until fixed what would be the step to resolve, as also the restore of database failed? What can I do to restore/clean/upgrade again?
BTW: it is a self hosted engine
Thanks, Gianluca
On Fri, Aug 3, 2018 at 2:14 PM, Jan Siml <jsiml@plusline.net> wrote:
Hello,
There are probably some more stale image transfers records,
can you please check whether 'image_transfers' table is empty? If not, you can try removing them by executing: "DELETE FROM image_transfers WHERE command_id NOT IN (SELECT command_entities.command_id FROM command_entities);" (you can simply prepend it to '04_02_1210_add_foreign_key_to _image_transfers.sql')
that's how it worked and the update was successful. Thanks!
Regards
Jan _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/communit y/about/community-guidelines/ List Archives: https://lists.ovirt.org/archiv es/list/users@ovirt.org/message/RQS4MHPWU7HWCZH6BIELHVGPB4BMBBGL/
On Fri, Aug 3, 2018 at 2:14 PM, Jan Siml <jsiml@plusline.net> wrote:
Hello,
There are probably some more stale image transfers records,
can you please check whether 'image_transfers' table is empty? If not, you can try removing them by executing: "DELETE FROM image_transfers WHERE command_id NOT IN (SELECT command_entities.command_id FROM command_entities);" (you can simply prepend it to '04_02_1210_add_foreign_key_to _image_transfers.sql')
that's how it worked and the update was successful. Thanks!
Regards
Jan
Jan, are you saying that after your second update failure that failed also the the restore of the databases, you added the delete statement into the 04_02_1210_add_foreign_key_to_image_transfers.sql script? How? because the yum rollback phase completed in my case so under /usr/share/ovirt-engine/dbscripts/upgrade/ I currently don't have it... And the first update error leaves the engine down....
On Fri, Aug 3, 2018 at 3:52 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Fri, Aug 3, 2018 at 2:14 PM, Jan Siml <jsiml@plusline.net> wrote:
Hello,
There are probably some more stale image transfers records,
can you please check whether 'image_transfers' table is empty? If not, you can try removing them by executing: "DELETE FROM image_transfers WHERE command_id NOT IN (SELECT command_entities.command_id FROM command_entities);" (you can simply prepend it to '04_02_1210_add_foreign_key_to _image_transfers.sql')
that's how it worked and the update was successful. Thanks!
Regards
Jan
Jan, are you saying that after your second update failure that failed also the the restore of the databases, you added the delete statement into the 04_02_1210_add_foreign_key_to_image_transfers.sql script? How? because the yum rollback phase completed in my case so under /usr/share/ovirt-engine/dbscripts/upgrade/ I currently don't have it... And the first update error leaves the engine down....
the snippet of the failed engine db restore inside log file is: 2018-08-03 14:15:47,017+0200 INFO otopi.ovirt_engine_setup.engine_common.database database.restore:869 Restoring file '/var/lib/ovirt-engine/backups/engine-20180803141347.gdQfiz.dump' to database localhost: engine. 2018-08-03 14:15:47,017+0200 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execu tePipeRaw:481 executePipeRaw: [0] popen kw={'stdin': None, 'stdout': -1, 'preexec_fn': <function _enabl eSignals at 0x35fab18>, 'env': {'PGPASSWORD': '', 'LESSOPEN': '||/usr/bin/lesspipe.sh %s', 'SSH_CLIENT' : '192.168.1.211 56098 22', 'SELINUX_USE_CURRENT_RANGE': '', 'LOGNAME': 'root', 'USER': 'root', 'HOME': '/root', 'PATH': '/opt/rh/rh-postgresql95/root/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/b in:/root/bin', 'LD_LIBRARY_PATH': '/opt/rh/rh-postgresql95/root/usr/lib64', 'LANG': 'en_US.UTF-8', 'TER M': 'xterm-256color', 'SHELL': '/bin/bash', 'LIBRARY_PATH': '/opt/rh/rh-postgresql95/root/usr/lib64', ' SHLVL': '5', 'HISTSIZE': '1000', 'POSTGRESQLENV': 'COMMAND/pg_dump=str:/opt/rh/rh-postgresql95/root/usr /bin/pg_dump COMMAND/psql=str:/opt/rh/rh-postgresql95/root/usr/bin/psql COMMAND/pg_re store=str:/opt/rh/rh-postgresql95/root/usr/bin/pg_restore COMMAND/postgresql-setup=str:/opt/rh /rh-postgresql95/root/usr/bin/postgresql-setup OVESETUP_PROVISIONING/postgresService=str:rh-po stgresql95-postgresql OVESETUP_PROVISIONING/postgresConf=str:/var/opt/rh/rh-postgresql95/lib/p gsql/data/postgresql.conf OVESETUP_PROVISIONING/postgresPgHba=str:/var/opt/rh/rh-postgresql95/ lib/pgsql/data/pg_hba.conf OVESETUP_PROVISIONING/postgresPgVersion=str:/var/opt/rh/rh-postgres ql95/lib/pgsql/data/PG_VERSION', 'MANPATH': '/opt/rh/rh-postgresql95/root/usr/share/man:', 'X_SCLS': 'r h-postgresql95 ', 'XDG_RUNTIME_DIR': '/run/user/0', 'PYTHONPATH': '/usr/share/ovirt-engine/setup/bin/.. ::', 'PGPASSFILE': '/tmp/tmpM8aXOE', 'SELINUX_ROLE_REQUESTED': '', 'MAIL': '/var/spool/mail/root', 'PKG _CONFIG_PATH': '/opt/rh/rh-postgresql95/root/usr/lib64/pkgconfig', 'XDG_SESSION_ID': '4386', 'sclenv': 'rh-postgresql95', 'LS_COLORS': 'rs=0:di=38;5;27:ln=38;5;51:mh=44;38;5;15:pi=40;38;5;11:so=38;5;13:do=3 8;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=05;48;5;232;38;5;15:su=48;5;196;38;5 ;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex . . . 'XDG_CONFIG_DIRS': '/etc/opt/rh/rh-postgresql95/xdg:/etc/xdg', 'SSH_TTY': '/dev/pts/1', 'HOSTNAME': 'ovirt.lutwyn.org', 'JAVACONFDIRS': '/etc/opt/rh/rh-postgresql95/java:/etc/java', 'SELINUX_LEVEL_REQUESTED': '', 'HISTCONTROL': 'ignoredups', 'XDG_DATA_DIRS': '/opt/rh/rh-postgresql95/root/usr/share', 'PWD': '/root', 'CPATH': '/opt/rh/rh-postgresql95/root/usr/include', 'OTOPI_LOGFILE': '/var/log/ovirt-engine/setup/ovirt-engine-setup-20180803140934-1thg3k.log', 'SSH_CONNECTION': '192.168.1.211 56098 192.168.1.212 22', 'OTOPI_EXECDIR': '/root'}, 'close_fds': True, 'args': ['/opt/rh/rh-postgresql95/root/usr/bin/pg_restore', '-w', '-h', 'localhost', '-p', '5432', '-U', 'engine', '-d', 'engine', '--jobs=2', '/var/lib/ovirt-engine/backups/engine-20180803141347.gdQfiz.dump'], 'stderr': -1} 2018-08-03 14:15:47,041+0200 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.executePipeRaw:486 executePipeRaw: [0] pid pid=10100 2018-08-03 14:16:03,535+0200 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.executePipeRaw:603 executePipe-result: [0] ['/opt/rh/rh-postgresql95/root/usr/bin/pg_restore', '-w', '-h', 'localhost', '-p', '5432', '-U', 'engine', '-d', 'engine', '--jobs=2', '/var/lib/ovirt-engine/backups/engine-20180803141347.gdQfiz.dump'], rc=1 2018-08-03 14:16:03,536+0200 DEBUG otopi.ovirt_engine_setup.engine_common.database database.restore:922 db restore rc 1 stderr ['pg_restore: [archiver (db)] Error while PROCESSING TOC:', 'pg_restore: [archiver (db)] Error from TOC entry 7251; 0 0 COMMENT EXTENSION plpgsql ', 'pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql', " Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';", '', '', '', 'pg_restore: [archiver (db)] Error from TOC entry 7252; 0 0 COMMENT EXTENSION "uuid-ossp" ', 'pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension uuid-ossp', ' Command was: COMMENT ON EXTENSION "uuid-ossp" IS \'generate universally unique identifiers (UUIDs)\';', '', '', '', 'pg_restore: WARNING: column "user_role_title" has type "unknown"', 'DETAIL: Proceeding with relation creation anyway.', 'pg_restore: WARNING: no privileges could be revoked for "public"', 'pg_restore: WARNING: no privileges could be revoked for "public"', 'pg_restore: WARNING: no privileges were granted for "public"', 'pg_restore: WARNING: no privileges were granted for "public"', 'WARNING: errors ignored on restore: 2'] 2018-08-03 14:16:03,536+0200 ERROR otopi.ovirt_engine_setup.engine_common.database database.restore:937 Errors while restoring engine database, please check the log file for details 2018-08-03 14:16:03,536+0200 DEBUG otopi.ovirt_engine_setup.engine_common.database database.restore:942 Errors unfiltered during restore: pg_restore: [archiver (db)] Error from TOC entry 7252; 0 0 COMMENT EXTENSION "uuid-ossp" pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension uuid-ossp 2018-08-03 14:16:03,537+0200 DEBUG otopi.context context.dumpEnvironment:859 ENVIRONMENT DUMP - BEGIN 2018-08-03 14:16:03,537+0200 DEBUG otopi.context context.dumpEnvironment:869 ENV BASE/error=bool:'True' 2018-08-03 14:16:03,537+0200 DEBUG otopi.context context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[(<type 'exceptions.RuntimeError'>, RuntimeError('Engine schema refresh failed',), <traceback object at 0x412ad40>)]' 2018-08-03 14:16:03,539+0200 DEBUG otopi.context context.dumpEnvironment:873 ENVIRONMENT DUMP - END 2018-08-03 14:16:03,539+0200 INFO otopi.context context.runSequence:741 Stage: Clean up 2018-08-03 14:16:03,539+0200 DEBUG otopi.context context.runSequence:745 STAGE cleanup 2018-08-03 14:16:03,541+0200 DEBUG otopi.context context._executeMethod:128 Stage cleanup METHOD otopi.plugins.otopi.dialog.answer_file.Plugin._generate_answer_file 2018-08-03 14:16:03,541+0200 DEBUG otopi.context context.dumpEnvironment:859 ENVIRONMENT DUMP - BEGIN 2018-08-03 14:16:03,542+0200 DEBUG otopi.context context.dumpEnvironment:869 ENV DIALOG/answerFileContent=str:'# OTOPI answer file, generated by human dialog [environment:default] QUESTION/1/ENGINE_VACUUM_FULL=str:yes QUESTION/1/OVESETUP_CORE_ENGINE_STOP=str:ok QUESTION/1/OVESETUP_DWH_PERFORM_BACKUP=str:yes QUESTION/1/OVESETUP_UPDATE_FIREWALL=str:yes QUESTION/1/OVESETUP_DIALOG_CONFIRM_SETTINGS=str:ok QUESTION/1/DWH_VACUUM_FULL=str:yes QUESTION/1/OVESETUP_RPMDISTRO_PACKAGE_UPGRADE=str:yes ' 2018-08-03 14:16:03,543+0200 DEBUG otopi.context context.dumpEnvironment:873 ENVIRONMENT DUMP - END 2018-08-03 14:16:03,544+0200 DEBUG otopi.context context._executeMethod:128 Stage cleanup METHOD otopi.plugins.ovirt_engine_common.base.core.misc.Plugin._cleanup
Hello, On 03.08.2018 15:52, Gianluca Cecchi wrote:
On Fri, Aug 3, 2018 at 2:14 PM, Jan Siml <jsiml@plusline.net <mailto:jsiml@plusline.net>> wrote:
Hello,
There are probably some more stale image transfers records, can you please check whether 'image_transfers' table is empty? If not, you can try removing them by executing: "DELETE FROM image_transfers WHERE command_id NOT IN (SELECT command_entities.command_id FROM command_entities);" (you can simply prepend it to '04_02_1210_add_foreign_key_to_image_transfers.sql')
that's how it worked and the update was successful. Thanks!
Jan, are you saying that after your second update failure that failed also the the restore of the databases, you added the delete statement into the 04_02_1210_add_foreign_key_to_image_transfers.sql script? How? because the yum rollback phase completed in my case so under /usr/share/ovirt-engine/dbscripts/upgrade/ I currently don't have it... And the first update error leaves the engine down....
I checked the table in psql and found only one row. Then I used the above statement to delete the orphaned row and retried the update. Worked. Regards Jan
On Fri, Aug 3, 2018 at 4:09 PM, Jan Siml <jsiml@plusline.net> wrote:
Hello,
On 03.08.2018 15:52, Gianluca Cecchi wrote:
On Fri, Aug 3, 2018 at 2:14 PM, Jan Siml <jsiml@plusline.net <mailto: jsiml@plusline.net>> wrote:
Hello,
There are probably some more stale image transfers records, can you please check whether 'image_transfers' table is empty? If not, you can try removing them by executing: "DELETE FROM image_transfers WHERE command_id NOT IN (SELECT command_entities.command_id FROM command_entities);" (you can simply prepend it to '04_02_1210_add_foreign_key_to_image_transfers.sql')
that's how it worked and the update was successful. Thanks!
Jan, are you saying that after your second update failure that failed also the the restore of the databases, you added the delete statement into the 04_02_1210_add_foreign_key_to_image_transfers.sql script? How? because the yum rollback phase completed in my case so under /usr/share/ovirt-engine/dbscripts/upgrade/ I currently don't have it... And the first update error leaves the engine down....
I checked the table in psql and found only one row. Then I used the above statement to delete the orphaned row and retried the update. Worked.
Regards
Jan
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? In my case after first run failure, my engine is down and trying to reach I get: " Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. " - 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? Gianluca
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.
In my case after first run failure, my engine is down and trying to reach I get: " Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. "
- 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
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
participants (5)
-
Daniel Erez -
Gianluca Cecchi -
Greg Sheremeta -
Jan Siml -
Vaibhav Pagar