Re: New HDB backend MDB

On Mon, Dec 12, 2011 at 6:45 PM, Howard Chu <[email protected]> wrote:
> Nico Williams wrote:
> All that matters is that we are using the same size pages as the OS demand
> pager. E.g. on Linux you won't see these sizes increasing any time soon,
> since huge pages are not actually pageable.

I suppose that's likely to be true all around.  But! the standard says
this about getpagesize(): "Also the behaviour is not specified for
this interface on systems that support variable size pages."  And it
says nothing about about the sysconf() equivalent other than that
getpagesize() is deprecated in favor of sysconf.

I think using _SC_PAGE_SIZE is asking for trouble, even if you're
lucky enough that it just works everywhere today.

> The pagesize is actually stored in the DB; a vestige from earlier designs
> where I intended to make it configurable. I've since chosen not to provide
> that option.

Hmmm, well, I think it'd be better to have it be configurable, but
that can always be added later.  As long as the page size appears in
the ubberblock and is read from there and honored when the DB is
opened, that's enough to make it configurable later.

>> Also, it'd be nice to have file magic for MDB, and nicer still if
>> MDB-used-to-backend-SQLite3 was recognizable as such from file magic.
>> I like file(1) to be useful :)  besides, you could then have SQLite3
>> use the correct backend after tasting the file!
>
> That can be arranged. There is already a 32 bit magic number for MDB files.
> The offset of the magic number will depend on whether it was created on a
> 32bit or 64bit architecture. The magic number is either 12 bytes in (32 bit)
> or 16 bytes in (64 bit). The magic number was chosen to reflect endianness
> as well (0xBEEFC0DE).

Great!  Thanks,

Nico
--