Søren Holm wrote: > > > Den 08.09.2022 kl. 17.30 skrev Howard Chu: >> Ulrich Windl wrote: >>>>>> Howard Chu <[email protected]> schrieb am 08.09.2022 um 01:34 in Nachricht >>> <[email protected]>: >>>> Steffen Michels wrote: >>>>> Hi, >>>>> >>>>> We are considering using the mdb.master3 branch of LMDB, but it is not >>>>> clear >>>> to me whether the data.mdb format will remain stable. Is there a chance >>>> that >>>>> another migration of all databases will be required in the future when >>>> switching now? >>>> >>>> Yes. It is still unreleased because additional changes to the freelist >>>> format are planned, >>>> and possibly a few other changes. >>>> >>>> In any case, mdb_dump/mdb_load will always work for migrating to a new >>>> version. >>> >>> I think at some point an inplace upgrade would be the way to go. >>> On Linux filesystems, you could even upgrade yout ext3 to btrfs ;-) >> >> That will never happen here. Supporting an in-place upgrade requires the >> library to support >> old and new formats simultaneously, which is a waste of RAM. Anything that >> pushes the object >> code size of the hot path over 64KB is a non-starter. > > Well - if the old version is kept in it's own memory region the new version > will still fit within it's own 64KB region. > > If the library should not contain both how would you image an application > managing the upgrade by itself. I mean, the symbols are names the same etc. > so it is > difficult to link with both the old and new version.
A database upgrade is an administrative change, thus handled by the administrative tools mdb_dump/mdb_load. There's no need to handle it in an application's main runtime code. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
