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/