[email protected] 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/
