i believe this IRC discussion effectively describes the problem, and the proposed solution:

hunmonk: killes: i think we may have a bug in the upgrade path after your cache patch

hunmonk: killes: statistics_init calls drupal_get_title(), which eventually can call menu_get_menu()--that has a call to the cache table

hunmonk: killes: so if statistics module is enabled on a site when they go to do the upgrade, there will be problems most likely

hunmonk: killes: for me, it was going into an infinite loop and bombing out until i commented out the call to the cache

hunmonk: killes: since the cache is embedded so deeply in the code calls, i would suggest we move that table adjustment into the same place as update_fix_access_table() in update.php

hunmonk: killes: my guess is that will save us a lot of upgrade headaches

killes: hunmonk: yeah, that sounds like a good idea

CommentFileSizeAuthor
#6 update_cache_0.patch.txt6.46 KBheine
#1 update_cache.patch.txt6.13 KBheine

Comments

heine’s picture

heine commented
Status: Active » Needs review
StatusFileSize
new update_cache.patch.txt6.13 KB

I've moved the update function to update.php.

killes@www.drop.org’s picture

killes@www.drop.org commented

looks good to me, somebody should try it.

dww’s picture

dww
we/he/they
commented
Status: Needs review » Reviewed & tested by the community

tested patch from #1 on both mysql (4.1.19) and pgsql (8.1.4). without the patch, updates fail with cache-related warnings. with the patch, everything works nicely (except for the fact that updates 1005 and 1006 are broken on pgsql, but i'll file those as separate issues). once this patch (along with http://drupal.org/node/82524 and http://drupal.org/node/82806) are applied, update.php itself works fine. reviewed the code (as did killes) and it looks fine to my eyes. tested and works. RTBC.

dww’s picture

dww
we/he/they
commented
Status: Reviewed & tested by the community » Needs work

sorry, i RTBC'ed a little bit too soon. now that i got the pgsql problems figured out in updates 1005 (http://drupal.org/node/82822) and 1006 (http://drupal.org/node/82823) i'm still getting a few lingering cache-related table errors when updating:

* warning: pg_query(): Query failed: ERROR: relation "cache_page" does not exist in /Users/wright/drupal/cvs/head/core.cvs/includes/database.pgsql.inc on line 119.

* user warning: query: DELETE FROM cache_page WHERE expire != 0 AND expire < 1157609683 in /Users/wright/drupal/cvs/head/core.cvs/includes/database.pgsql.inc on line 138.

* warning: pg_query(): Query failed: ERROR: relation "cache_page" does not exist in /Users/wright/drupal/cvs/head/core.cvs/includes/database.pgsql.inc on line 119.

* user warning: query: TRUNCATE TABLE cache_page in /Users/wright/drupal/cvs/head/core.cvs/includes/database.pgsql.inc on line 138.

* warning: pg_query(): Query failed: ERROR: relation "cache_menu" does not exist in /Users/wright/drupal/cvs/head/core.cvs/includes/database.pgsql.inc on line 119.

* user warning: query: TRUNCATE TABLE cache_menu in /Users/wright/drupal/cvs/head/core.cvs/includes/database.pgsql.inc on line 138.

i'm getting those errors but none of the updates are being marked as failure. no time right now to investigate more closely... if possible, i'll try to hunt this down in the near future. otherwise, i'm sure heine can/will roll a new patch. ;)

dww’s picture

dww
we/he/they
commented
Status: Needs work » Reviewed & tested by the community

sorry, too many damn update.php bugs and patches floating around in my workspace right now. :( turns out i had undone heine's patch at some point to test something else, and forgot to reapply it when i finished testing the 1005 and 1006 pgsql update errors. now that his patch is *applied* in my workspace, the errors go away. ;) moving this back to RTBC, where it belongs. apologies for the false alarm.

heine’s picture

heine commented
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new update_cache_0.patch.txt6.46 KB

New patch with all create table statements wrapped in if (!db_table_exists()) clauses.

dww’s picture

dww
we/he/they
commented
Status: Needs review » Reviewed & tested by the community

patch from #6 re-introduces the errors we're trying to fix here. -1 to that. ;) if/when we want to wrap all create table calls with the check to db_table_exists(), let's just do it in a completely separate issue (which webchick already submitted: http://drupal.org/node/82810).

i'm setting this issue back to RTBC in favor of the patch from #1. please commit that, and let's forget about the db_table_exists() stuff in here. let's move all such effort into #82810 where it belongs, so as not to delay or complicate this otherwise fairly simple fix.

thanks,
-derek

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Reviewed & tested by the community » Fixed

Committed to HEAD.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)