`Database` defaults `max_db_size` to 1 GiB on all platforms, contradicting its docstring (8 TiB on 64-bit)

[RP38]

---

Environment

• ladybug 0.16.1 (PyPI)
• Python 3.12, 64-bit Linux

Summary

Database.__init__ hardcodes max_db_size = (1 << 30) (1 GiB) regardless of platform, but its own docstring documents the default as 1 << 43 (8 TiB) on 64-bit systems (and 1 GiB only on 32-bit). On 64-bit hosts the effective default is therefore ~8000× smaller than documented.

Evidence (ladybug/database.py)

Default, line 42:

max_db_size: int = (1 << 30),

Docstring for the same parameter, lines 80–85:

max_db_size : int
    The maximum size of the database in bytes. Note that this is introduced
    temporarily for now to get around with the default 8TB mmap address
    space limit some environment. ... The value is default to 1 << 43 (8TB)
    under 64-bit environment and 1GB under 32-bit one.

Confirmed via the public signature:

>>> import inspect, ladybug
>>> inspect.signature(ladybug.Database.__init__).parameters["max_db_size"].default
1073741824   # 1 GiB, on 64-bit Python

Expected

On a 64-bit environment, Database(path) with no max_db_size should use the documented 1 << 43 default (or the wrapper should detect the platform), matching the docstring.

Actual

The cap is 1 GiB on every platform. Once a database grows past 1 GiB, ingestion fails with a buffer-manager error that gives no indication the cause is a size cap:

RuntimeError: Buffer manager exception: No more frame groups can be added to the allocator.

…raised from Connection.execute(...) during a COPY. The fix on our side was simply Database(path, max_db_size=1 << 40), which confirms the 1 GiB default was the cause.

Impact

• The opaque error message gives no hint that max_db_size is the lever, costing debugging time.
• Anyone relying on the documented default silently gets a 1 GiB ceiling.

Suggested fix

Either set the signature default to the documented platform-dependent value (1 << 43 on 64-bit), or — if 1 GiB is intentional — correct the docstring and ideally make the buffer-manager error mention the max_db_size limit.

[aheev]

Thanks for reporting the issue. It is supposed to default to DEFAULT_VM_REGION_MAX_SIZE, as stated in the docstring. We'll get this fixed.

@adsharma should we get rid of per lang binding default setting across bindings?

[adsharma]

Yes - we should remove this setting which creeped in without me noticing. But let's also test that it doesn't regress memory usage on the benchmark runs. That is confirm that the improved memory usage stats in python runs is because of changed in memory management strategy and not max_db_size.

[adsharma]

For now, it can be changed via a parameter passed in to Database constructor. Sometimes the 8TB virtual can be a problem.