[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: mm_last_pg+1 != filesize

Hallvard Breien Furuseth wrote:

On 22/12/15 08:23, Howard Chu wrote:

Hallvard Breien Furuseth wrote:

Do env_sync() and commit() survive the test program from ITS#7886?
It creates a datafile which ends before mm_last_pg+1.


That would probably crash on Windows, I'll check it later. Annoying that
Windows doesn't just flush whatever exists and move on.

Could add a filesize check to env_open and fail if last_pgno doesn't
match.


Not enough if there are several writer processes.
For a growing file, the check would have to go in mdb_txn_begin().


Not an issue. The test program from its7886 runs just fine.


I'm not too fussed about it, you have to be deliberately
malicious to create this condition. You get a Bus Error or a SEGV -
that's a lot safer than tamely returning an error code that the caller
could ignore.


Not malicious.  Omit some commits like slapadd -q does, and it can happen
naturally.  Maybe slapadd -q can do just that with large IDLs.
The change in question was for msync, which is only used for MDB_WRITEMAP. On Windows, for WRITEMAP, we always have to expand the file to make sure referenced pages exist, before referencing them. The filesize growth occurs regardless of whether a subsequent commit happens or not. 

Regular fdatasync doesn't require a length parameter, so it's irrelevant.


I think MDB_meta and MDB_txn need "last written page" maintained
by mdb_page_flush().  Can VL32 wait for MDB_DATA_VERSION > 1?


mdb_page_flush() already maintains last_pgno for MDB_VL32.

There is no issue here.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/