[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/