[wp-trac] [WordPress Trac] #24958: Large number of revisions cause memory exhaustion

[WordPress Trac]

#24958: Large number of revisions cause memory exhaustion
--------------------------+--------------------
 Reporter:  jshreve       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.6.1
Component:  Revisions     |     Version:  3.6
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+--------------------

Comment (by nacin):

 My comment was pretty in depth, which shouldn't make it ''too'' difficult
 for someone to come up with a patch, but it is still fairly complicated,
 and might require some enhancements to WP_Query or a less-than-triumphant
 return of [http://core.trac.wordpress.org/browser/tags/3.5/wp-
 includes/post.php#L4994 _wp_get_post_autosave_hack()] to do some hijinks.
 Or, a direct query.

 For 3.6.1 I think we should either do `@ini_set( 'memory_limit',
 apply_filters( 'admin_memory_limit', WP_MAX_MEMORY_LIMIT ) );` or do
 `'posts_per_page' => 1000`.

 That said, WordPress.com is running an opcode cache (i.e. APC) which means
 the actual memory of the current process is possibly lower than what might
 be typical in the non-opcode admin (mid 20s MB). (This might not be true
 since WP.com runs a metric ton of extra code.) We should test how much
 memory 1000 revisions actually requires (and compare to both frontend and
 admin) and see if limiting to 1000 makes sense.

 I'm fine with limiting to 1000 (if that's not too high) as a "dude,
 seriously?" number to avoid fatal errors. And it is, of course,
 filterable.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/24958#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software