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
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"
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/