Search module loads every comment into memory

If there are thousands of comments on a node, and a site editor disables commenting on the node, without deleting or disabling the comments themselves, a cron run will choke and run out of memory, as ALL the comments are loaded into memory at once.

Site editors who have run into spam problems, who find that there are thousands of spam comments on a node, will naturally edit the node and disable comments, rather than the more lengthy process of deleting all the problematic nodes. This is not the "right" way to do it, but this is what the end user will do, every time, because it's easy.

search_cron() will actually invoke comment_nodeapi($op = 'update index') when the comment module is enabled. If this happens, this case will run:

case 'update index':
  $text = '';
  $comments = db_query('SELECT subject, comment, format FROM {comments} WHERE nid = %d AND status = %d', $node->nid, COMMENT_PUBLISHED);
  while ($comment = db_fetch_object($comments)) {
    $text .= '<h2>' . check_plain($comment->subject) . '</h2>' . check_markup($comment->comment, $comment->format, FALSE);
  }
  return $text;

This selects all the comments for a given node. This is then passed to the search indexer, which runs a lot of preg_split() on them, quickly filling up the available memory.

I tried this with 12MB of comments, 1200 in total (extreme, but not unreasonable for spammers), and a memory limit of 128MB, and it bailed every time.

The end result of this is that cron fails consistently, preventing other cron tasks from running, and preventing the search index from being updated.

I'd suggest that the PHP code above should check whether the node has comments disabled, and refuse to index comments on that node unless its comments are at least 'read only'.

Patch attached. Please go easy, as I have not submitted a patch to core before. Any tips on improving patches would be appreciated.