Description of problem: in rhn-upgrade documentation in step 3 we say to run: /usr/bin/update-packages --db=dbusername/dppassword@dbSID This is run in one big transaction, which will require a lot of UNDO_TBS. Additionaly if we run out of the space, the whole transaction is rollbacked, but some files is already moved and stay moved, which will introduce inconsitency between paths stored in db and path on file system. We should commit after each package/path move. But this will by probably slow, so due speed reason we may want to commit after let say 1000 moved packages. Version-Release number of selected component (if applicable): sat530 How reproducible: during upgrade Steps to Reproduce: 1. upgrade sat520 to sat530 2. during step 3 watch UNDO_TBS grow. 3. optionaly make sure you run out of UNDO_TBS in middle of transaction Actual results: slow and mess in db Expected results: fast and correct behavior.
Taking for now.
Fix to break up the transaction into smaller chunks so that we don't run out of the rollback space committed to Spacewalk master: d00dc3a5efd28f683fd680cabffb7ae969895900.
Note that the processPackageKeyAssociations function does commit, so if most of the packages have keys (?), during the first run (when the key records are being added to the database), the loop behaves as autocommit anyway.
Not undo_tbs related, but potentially useful changes: d4d824d468b2b682f7bc02b9f432fa5c75f5e5d6 and 714f2d07cbbd8e19ddde53f4e5a80c33b5f137ff, to provide small speedups.
satellite.git, SATELLITE-5.3: 18585b473f0e69af1704d2557c1aa946ff4a30a1
rhn-upgrade-5.3.0.24-1.el4sat & rhn-upgrade-5.3.0.23-1.el5sat
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1479.html