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

bgm’s picture

Hi,

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.

reikiman’s picture

mysql> select count(*) from boost_cache;
+----------+
| count(*) |
+----------+
|   367185 | 
+----------+
1 row in set (0.03 sec)

mysql> select count(*) from boost_cache_settings;
+----------+
| count(*) |
+----------+
|        0 | 
+----------+
1 row in set (0.02 sec)

mysql> select count(*) from boost_cache_relationships;
+----------+
| count(*) |
+----------+
|  1100561 | 
+----------+
1 row in set (0.02 sec)

mysql> select count(*) from boost_crawler;
+----------+
| count(*) |
+----------+
|        0 | 
+----------+
1 row in set (0.02 sec)

reikiman’s picture

Emptying the tables let the update run correctly.

bgm’s picture

Status: Active » Fixed

I 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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.