Hi Howard, thanks a lot for your answers.
No, the data size is limited to 4294967295 bytes.
Oh, I missed two "f"s in the constant ;-)
- I discovered the return code "MDB_TXN_FULL". By what means are transactions limited? I might consider to use few, but quite large transactions dealing with hundreds of thousands key/value pairs to be created, updated or deleted in some circumstances.The limit has mostly been removed, although large transactions will probably have a performance penalty.
Sure, I don't expect that to happen in a second anyway. But if the cost of a key/value op is still less linear, it would be fine to me, as the situation would occur rather seldom.
- I saw the discussion about the predefined database size, and that it is recommended to use a never-to-be-reached size and to rely on the sparse file capabilities of the underlying OS. If I would not want to go this way: Is it correct that if I encounter an "MDB_MAP_FULL" return code, it would be sufficient to abort the current transaction, resize the database using mdp_env_set_mapsize and repeat the transaction?Yes, as long as you follow the other restrictions on changing the size.
You mean that a separate (reader) process would have to react on the changed file size also (MDB_MAP_RESIZED result)? Or are there any further things to observe that I missed?
Regards, Klaus