I have had 6.x-1.18 installed and was just updating to the latest modules and tried to run the update, but the update hung. Like the following transcript. I diddled around a little bit and couldn't come up with anything. I did "drush dis boost" to disable it, and it still insisted on running the update for boost. Next I completely rm'd the boost module directory, and copied in the 6.x-1.18 version I had been running, and ran the update again. This time "drush updb" of course only tried to update the flag module. That leaves my site running with a slightly out-of-date Boost module, but at least the site is running.
[ps47533]$ drush updb
The following updates are pending:
boost module
6128 - Update 6128 increase page_id from 64 to 255.
6129 - Update 6129 Remove unique key on hash in boost_crawler.
flag module
6205 - Provide a better index on the flag_content table to include 'uid' and 'sid'.
6206 - Correction to flag_update_6205(). Convert unique key to an index.
6207 - Adds column last_updated to flag_counts table.
6208 - Convert flag_count indexes to include FID for more efficient indexing.
6209 - Clean up orphaned flags due to node and comment deletion.
6210 - Add an index to help with view's flag_handler_relationship when not required.
Do you wish to run all pending updates? (y/n): y
^C
Comments
Comment #1
bgm CreditAttribution: bgm commentedHi,
Can you run the following SQL commands?
select count(*) from boost_cache;
select count(*) from boost_cache_settings;
select count(*) from boost_cache_relationships;
select count(*) from boost_crawler;
The upgrade adds fields and indexes. If the tables are huge, it might be causing a performance issue. Truncating the tables might be an option. Often, the culprit is the 'boost_cache_settings' table, which includes per-page expiration info. When combined to Solr, for example, it becomes really big.
Comment #2
reikiman CreditAttribution: reikiman commentedComment #3
reikiman CreditAttribution: reikiman commentedEmptying the tables let the update run correctly.
Comment #4
bgm CreditAttribution: bgm commentedI noticed on some sites that in 6.x-1.18, the boost_cache_relationships table tends to get out of control. After the 6.x-1.20 upgrade, it seems to work a bit better, so I suspect some bugs were fixed.
Committed a fix to truncate the table before the updates that affect that table.