Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
because they use the default engine type which is myISAM in most cases. This small patch fixes this to use in-memory HEAP tables instead. It degrades gracefully to iuse MyISAm should HEAP not be available.
Comment | File | Size | Author |
---|---|---|---|
#20 | heap.d5.patch | 1.64 KB | Freso |
#8 | heap_0.patch | 1.61 KB | killes@www.drop.org |
heap.patch | 1.61 KB | killes@www.drop.org | |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedseems like a good idea. subscribing
Comment #2
m3avrck CreditAttribution: m3avrck commentedHow does this affect memory usage on the server? Is there a recommended "make an extra 128kb available" type deal?
Sounds like a great idea!
Comment #3
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedThere will be of course higher memory usage, but I am not sure how big it will be. The tables are usually not that big and the memory should be reclaimed at the end of the page request.
Comment #4
brashquido CreditAttribution: brashquido commentedNot being any sort of MySQL guru I'd assume you'd do this for a performance improvement? Any idea what kind of ball park improvement you'd get by doing this?
Comment #5
m3avrck CreditAttribution: m3avrck commentedAFAIK, this only affects searching, that is the only module in core that makes use of it. Views_search makes use of it as well.
Comment #6
Souvent22 CreditAttribution: Souvent22 commentedSubscribing
Comment #7
pwolanin CreditAttribution: pwolanin commentedBased on the docs on mysql.com, it seems the right approach for such a temporary table. I think I saw somewhere else that this is already running on drupal.org?
http://dev.mysql.com/doc/refman/4.1/en/memory-storage-engine.html
Comment #8
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedIndeed, this patch is running without a problem on drupal.org for about two months or so. I've rerolled it to remove fuzz and declare it ready to go.
Comment #9
Steven CreditAttribution: Steven commentedCommitted to HEAD. Should this be backported to 5?
Comment #10
Steven CreditAttribution: Steven commentedComment #11
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedIMO yes. If Neil applies this to 5 I'll apply it to 4.7.
Comment #12
moshe weitzman CreditAttribution: moshe weitzman commentedI don't see how this could be called a bug, and thus i am a bit suspicious about backport. my .02
Comment #13
kbahey CreditAttribution: kbahey commentedThere is potentially scenarios where memory could be exhausted, e.g. on shared accounts.
Just to make sure this will not break memory limits, can we please have this simple patch run on Drupal.org for a week or so, with this line added:
watchdog('debug', 'Temp table search rows: ' . $count);
Before the line:
$count_query = "SELECT $count";
in do_search() in search.module.
I am more concerned about common terms that return too many rows, e.g. "drupal" or "module".
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedI updated my development area and all of a sudden I was getting an invalid filename for some C:\TEMP file. The log message is below:
I reverted this patch and things began working again. This error occurred following a successful install.php before creating the id 1 user.
Comment #15
Anonymous (not verified) CreditAttribution: Anonymous commentedI updated my development area and all of a sudden I was getting an invalid filename for some C:\TEMP file. The log message is below:
I reverted this patch and things began working again. This error occurred following a successful install.php before creating the id 1 user.
Comment #16
Anonymous (not verified) CreditAttribution: Anonymous commentedI updated my development area and all of a sudden I was getting an invalid filename for some C:\TEMP file. The log message is below:
I reverted this patch and things began working again. This error occurred following a successful install.php before creating the id 1 user.
Comment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedApologies. I had received a ``500 - Internal Server Error'' in posting and had ass-u-me-d that the post had not been posted.
Comment #18
Heine CreditAttribution: Heine commentedHow did you reach that conclusion?
Error 13 means "OS error code 13: Permission denied" on WinXP. Can you please check the privileges of the user account that runs the mysql server? Also, check whether the file already exists, but is simply not writeable by the current user (example: another user created such a file).
# is a perfectly valid character on NTFS and FAT32.
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous commented@Heine: Thanks for pointing out my fallicies based on what I believed to be an MS limitation just because it was MS. The ``Permission Denied'' error is being caused by slow closing of handles of the open file and the create request for the file happens before all handles to the file are closed. This seems to be prevalent on my system with some unknown criteria exacerbating the issue. I hope to try again to see the frequency of the issue. I now conclude that this is not a bug for Drupal but may cause issues to arrise as if it were. Therefore, it may be wise to consider filtering the patch to LAMP only but waiting for issues about it to queue is also a worthy consideration. Another solution is to make this use configurable.
Comment #20
Freso CreditAttribution: Freso commentedWhether it should go into D5 or not is not my call, but here's a port for 5.x anyway. (Not tested.)
Comment #21
drummThis looks like a good idea, but will need testing in a couple hosting environments.
Comment #22
drummHasn't been an issue in D6 for over a year, so committed to 5.x.