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

Re: (ITS#8209) Broken MDB_CP_COMPACT threading

I wrote:
> Compacting can verify that the written metapage claims
> enough DB pages.  But not the opposite - it should not
> fail if it claims too many pages since that would mean
> we can't compact a DB which has suffered page leaks.

Duh, yes the opposite too.  If there has been a page leak,
the root page number written in the new meta will be wrong.

> We could detect that and re-write the metas at the end,
> if the user requests it and the file is seekable.

Though there's no reliable "is file seekable?" test. lseek()
can do nothing but still return success on some devices.

Another (user) option:  Write a file which requires recovery.
We'll need something like that with incremental backups anyway.
Write dummy metapages at the beginning, with meta.mm_version
indicating the file must be recovered.  Write a final metapage
at the end, or try to seek and rewrite the beginning if the
user says so.

Recovery must be a separate program, or in mdb_env_open()
when we know the metapage is at the end - i.e. before mapping
and maybe expanding the file.