For RDONLY, don't get lockfile until we know datafile exists.
Also, don't try to create a new datafile for me_mfd if someone
deleted it after we got me_fd.
If a key has a single existing value, and then a put (MDB_MULTIPLE)
is done where the first of the multiple values matches the existing
value, the put would return SUCCESS without writing any of the
values. Fixed to loop to the next value as intended.
Ignore parent txn cursors since it is the current txn's dirty_list
which will be flushed. But check the current txn also when clearing,
since cursors can have pages which are dirty in a parent.
Check !mc_xcursor instead of !MDB_DUPSORT. Equivalent for valid
data, but a bit safer if the sub-DB flags are corrupt.
Pid locking needs a different lockfile-version: MDB_env's with and
without pid locking must not coexist, they can sabotage each other.
Store MDB_LOCK_FORMAT = (version | "use locking" flag) instead.
Treat unexpected errors as "don't know". Invert Pidcheck return
value, so nonzero including error codes = "the process may exist".
On Windows: Catch exited but still existing processes. Handle
undefined PROCESS_QUERY_LIMITED_INFORMATION.
On Unix: don't trust F_GETLK error to leave the input alone,
the fcntl() doc seems unclear.
Whenever we enter cursor_set() the sub-cursor's flag must be
cleared. If the new cursor position has valid subdata it will
be initialized again, if not then the sub-cursor has nothing
to point to.
(Restructuring for upcoming mdb_page_spill work.)
mdb_freelist_save() can't just Get() the destination, since
mdb_page_spill() may have put the destination in the read-only map.
TODO: Can this new put() modify the freelist, which would break it? The
final iteration's put() can shorten the node, the rest uses MDB_CURRENT.
We could set P_KEEP on dirty freeDB leaves and ovpages, since they are
all about to be modified. But the code in this commit must stay anyway,
if mdb should support dropping a 256G DB. I.e. too big for dirty_list.
Hallvard Furuseth