Update script breaks oddly [#61544]

I have found that there is a conflict between database patch 146 and database patch 159 that causes the database update to hang.

On this particular data set, or, on at least two datasets (http://drupal.org/node/61039)

All databases patches prior to 146 will hang at 159
all database patches subsequent to 146 do not hang at 159.

----------------

I decided to investigate this and to do so, opted to apply all the patches to the database in sequential order, in order to discover which patches failed and when. i did this without resetting the database, and starting from 140 and jumping up untill i found a number that worked:
the database was not reset in between

140 - fails at 47%
145 - fails at 40%
149 - fails at 32%
151 - fails at 27%
156 - fails at 12%
157 - fails at 8%
158 - fails at 4 %
159 - fails.

in order to discover if there was a conflict or if 159 worked, i reset the databse, and attempted again, this time backwards from 159, on each attempt i reset the database to a state that works in 4.6

159 passed
158 passed
150 passed
149 passed
148 passed
147 passed
146 -- failed
145 -- failed
140 -- failed

-- From this, I would deduce that there is a conflict introduced at 146 which causes failure at 159.

Comments

Comment #1

smithcorona commented 4 May 2006 at 18:02

There's been a lot of discussion of this topic at http://drupal.org/node/61039

Summary:

error occurs on #159, which is moving old revision data.

killes: may be as a result of too much data in the revisions table, therefore exceeding 'max_allowed_packet'

hound: can we skip #159?

killes: if you dont' care about your revisions, yes you can skip this

killes: also, it may not be dead, just taking a really really long time.

killes has submitted a patch, http://drupal.org/node/61867

hound modified update.php to set update_159_done = TRUE and also updates.inc so that if update_159_done is true then that update gets skipped, because he didn't really care for his revisions. he's happy.

hound also found an older discussion at http://drupal.org/node/40662
which shows that the tables created in 146 are filled in 158/159, and that there have been errors in the past.