[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#8813) MDB_VL32 causes MDB_TXN_FULL
markus@greenrobot.de wrote:
> On 21.10.19 17:14, Howard Chu wrote:
>> I believe this was fixed by commit=20
>> 7edf504106c61639a89b9a4e5987242598196932 in mdb.master.=20
>=20
> I can not confirm that this works.
>=20
> This is the stack trace where MDB_TXN_FULL is still returned with lates=
t=20
> mdb.master (note: line numbers shown here are off by 60 compared to=20
> mdb.master):
>=20
> mdb_rpage_get mdb.c:6196
> mdb_page_get mdb.c:6378
> mdb_page_search_lowest mdb.c:6492
> mdb_node_move mdb.c:8842
> mdb_rebalance mdb.c:9366
> mdb_page_merge mdb.c:9166
> mdb_rebalance mdb.c:9373
> mdb_cursor_del0 mdb.c:9426
> mdb_cursor_del mdb.c:811
>=20
>=20
> Code segment:
>=20
> if (tl[0].mid >=3D MDB_TRPAGE_MAX)
> =C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0 return MDB_TXN_FULL;
>=20
> Debugger shows tl[0].mid to be 4095.
You're free to define MDB_TRPAGE_MAX to a larger value. It just means
you increase the chance of overrunning the 2GB available address space.
There's no magic, you can't fit every 64bit database workload into only
a 32bit address space. When your transactions are too large, the normal
thing to do is commit more often so they don't grow so large.
--=20
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/