[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Possible transaction issue with LMDB
- To: openldap-technical@openldap.org
- Subject: Possible transaction issue with LMDB
- From: William Brown <william@blackhats.net.au>
- Date: Thu, 16 Aug 2018 20:03:30 +1000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= blackhats.net.au; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=pSZWNLwYJUW210aV27+tCJLqmuu/nE+UTZgCgoBpe Rg=; b=bnf7OgVcM3gv+xIr/Wpif345+jvuKZD42T3//ik16QXFq28VXlfnCWMFn raIuWP5zUkFl9ZxShJULfUjmTBts9fZ/idXaIJ2AYs3Bbds8c6KFOue6NLoXf1rU cR9IUWUhwS7K+KL7xNxiB1e1Gt1REHV+vIv1UC65QS+J2LDIWGQGlYORWIzSN9QN 9kia0mdEo2ADgMWRFZ81ja0g7Vatj1dHfaq2tkAS6pw6ivfFODeC2lZKj7ub/yWF FJfOEkLRNsfc+SrHMALQXFk8/HLZoSSJ/pniH3AruubNS5N4gzq0tiPKYU9iqB4w 5CqkUuVC9TCCdQZEFRU6ww1MBAngg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=pSZWNLwYJUW210aV27+tCJLqmuu/n E+UTZgCgoBpeRg=; b=uD80KG6icSxPz+TaLtcKD7TM2Eh3JD7swd2boiEfUN7Sf LNOwVidyrB/Wy+hkxk3Lr9Pshc7jLeWY7tTYYbhJrHLhcpO0Ve4Khf6u4WDLb7MN hPZScZNxMk+w3sHsYK5sckEdl5X4jO1mBBdKhss+QiysvJvLvJcVuiJIHgfHqIMY Bv2dRHDPnRKU8W79WILTVuioG12D58u+znJZYxuwXx94qQun1FiJk9KzFi9OwAs+ jw2x8CAXc58PdR6frHNYSDOL4AxObRcg3tDN37s7V/+MQPJk0sDo40X0kNwXU5rM iUOuSdHcQLGdFZ4Mw6cBX3qhv3FzDPhSF1zHUotIQ==
Hi there,
While doing some integration testing of LMDB I noticed that there may
be an issue with out of order transaction handling.
The scenario is:
Open Read TXN A
Open Write TXN X, and change values of the DB
Commit X
Open Read TXN B
Open Write TXN Y, and change values of the DB
Commit Y
Open Read TXN C
Abort/Close TXN B.
At this point, because of the page touch between A -> B and B -> C, B
now believes that the pages of A are the "last time" they are available
as they were all subsequently copied for TXN C. The pages of A are then
added to the freelists when B closes. When TXN A is read from the data
may have been altered due to future writes as LMDB attempts to use
previously allocated pages first.
This situation is more likely to arise on large batch writes, but could
manifest with smaller series of writes. This would be a silent issue,
as the over-written pages may be valid, and could cause data to
"silently vanish" inside of the read transaction A leading to
unpredictable results.
I hope that this report helps you to diagnose and resolve the issue.
--
Sincerely,
William