For databases with a large number of node revisions, node_update_7005() is prone to PHP timeout errors.
Use the batch processing system in node_update_7005() to only process one column at a time.
Commit patch.
None.
None.
I consistently have a timeout when I try to update my D6 database to D7. My node_revision(s) table has over 388400 entries in it and node_update_7005(); appears to be choking on that. I checked the system table and verified that node was on schema_version 7004 after the timeout.
When I do a describe node_revision, it has all but the 'sticky' column added. I tried adding it manually to my database and it ran for 19.2 seconds. Multiply that by four, and I can see why this update might be causing my problems.
Possible fixes that come to mind are to turn it into a batch or extend the execution timeout for the page (or both?).
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 968288-12.patch | 1013 bytes | thedavidmeister |
| #11 | 968288_node_update_7005_fix.patch | 1019 bytes | gaurav.goyal |
| #9 | 968288_node_update_7005_fix.patch | 1 KB | gaurav.goyal |
| #6 | node_update_7005_fix.patch | 981 bytes | fractile81 |
| #5 | node_update_7005_fix.patch | 1012 bytes | fractile81 |
Comments
Comment #1
fractile81 commentedAttached is a patch that converts this update to use batching. This fixed my problem.
Comment #3
fractile81 commentedTrying the patch again...
Comment #5
fractile81 commentedLast try, then I'll just let someone else figure out why the patch doesn't work. The actual change should work, though.
Comment #6
fractile81 commentedAnd now I just feel sheepish... UNIX-style EOL now!
Comment #7
fractile81 commentedCorrecting the metadata.
Comment #8
thedavidmeister commentedWithout any actual data to test with that would likely timeout, it's a bit hard to manually test this.
Code makes sense to me though upon an inspection.
My only criticism is that there should be a newline separating the two lines in the docbloc comment.
Also, patch needs a reroll:
Comment #9
gaurav.goyal commentedPatch is rerolled according to current codebase, so removing Needs reroll tag.
Comment #11
gaurav.goyal commentedCorrected if condition, resubmitting the patch.
Comment #12
thedavidmeister commentedThere was a slight whitespace error in that patch. I fixed it up here, but it's so minor I'm setting RTBC.
Comment #13
thedavidmeister commentedComment #14
thedavidmeister commentedComment #16
David_Rothstein commented12: 968288-12.patch queued for re-testing.
Comment #17
David_Rothstein commentedCrazy that this is necessary, but if it is that makes it major.
Shouldn't $sandbox['#finished'] be set to a fraction between 0 and 1 after each stage (so the progress bar is more realistic)? That's normally how it's done, and in fact setting to 1 at the end shouldn't even be necessary. See taxonomy_update_7011() for an example.
Comment #18
thedavidmeister commentedYes, technically you should set #finished to a number between 0 and 1 and it is not necessary to set it at all in the case that you want the loop to end. Funny, I updated the docs for that less than a month ago and totally missed this :( #2141221: hook_update_N() should document how to use $sandbox['#finished'].