Log file corruption at emerg level too
Improve compaction efficiency with a temp file.

Databases that are updated randomly by doc id cause compaction to be
noticably less efficient than possible. This is due to the order in
which the id_tree is written. The random updates cause the append only
btree to generate a noticeable amount of waste.

This patch works by writing the id_tree to a temporary file during
compaction and then streams this btree back to the compaction file
during a final pass.
Initial implementation of an external merge sort.

This is kinda weird running in a single file using append only storage
but I think it should work. Hopefully...
Update new compactor to use couch_emsort.

This uses the external merge sort to speed up the insertion of writing
docid data to disk and then the subsequent insertion back into the btree
in the .data file.
Separate sort and streaming in couch_emsort

We need a chance to write a new header to the meta file once merging has
completed.
Make a final commit after sorting the meta file

When retrying compaction that generated a large meta file we would take
a considerable amount of time seeking through the data generated by the
id merge sort. This would take so long that the fd for the data file
would be closed by couch_file (because it's not monitored yet) which
would then blow up when trying to read from it once we read the meta
file header.

This patch just sorts the meta file in one step, rewrites #comp_header{}
entries for both files and then does the streaming copy of ids to the
data file. This way when we retry the meta file will have a header right
at the end of the file so opening won't take a long time.
merge_docids/2 does not tag its return value
Notify users if an iterator can't be created

Instead of raising a function clause error this just tells the user that
the ems hasn't been merged yet.
Update iterator in recursive calls to merge_docids/2
Fix variable shadowing
Collapse dupes in views instead of crashing

Duplicate entries in a database's sequence tree can be introduced by the
bugs described in COUCHDB-968 and COUCHDB-1265.  The dupes will
propagate to any secondary indexes if they are sufficiently close enough
to each other in the seq tree.

This patch modifies the view compactor so that instead of crashing on
detection of dupes in the view index it collapses all the view keys into
a single entry for the document.  A subsequent indexing of the document
will remove the duped keys from the view and will replace them with the
correct output for the current revision of the doc.
Fork new OS processes outside proc_manager loop
Use a 'one_for_one' strategy in couch_server_sup
Ignore unexpected messages to couch_index_server
Remove stale optimization for compaction commits

Before the new compactor we hacked the fsync options to only commit once
before the header was written instead of before and after. This stale
override then lead to an issue where the final commit_data call didn't
fsync after a #db_header{} was written leaving a #comp_header{} as the
last valid header which lead to errors about corruption when opening the
database later on.
Allow processes to idle before exiting

When system load exceeds the ability of os_process_soft_limit to keep
up with demand we enter a fork-use-kill (FUK) cycle. The constant
spawning and destruction os these processes thrashes system resources
and causes general instability.

This patch changes the behavior from killing each process as its
returned to letting it idle for a configurable amount of time (default
five minutes) which allows it to be reused by other clients. This way we
can avoid adding unnecessary load when demand for couchjs processes
exceeds os_process_soft_limit.

As a happy benefit this should also allow os_process_soft_limit to be
set much lower since the number of processes will now more closely
follow actual demand (instead of provisioning for the worst case
scenario).
Add a code_change for addition of 'idle' to State
Mark proc as unused in ret_proc

Otherwise we'll never reuse it
Call reader and writer functions via export table

This is necessary for hot upgrades of the module.
Avoid scanning the entire table of procs

For large numbers of os processes its possible that we have a slowdown
when requesting a new process. The old code matches all possible
processes out of the table to find an appropriate candidate.

We avoid the issue by using ets:select_reverse to also prefer keeping
newer processes and releasing longer lived processes. Length of life is
based on the implicit sorting of pids having newer pids sorting larger.