Jeremy.
(cherry picked from commit 0bae1ef3de8fda5e1e2d641b14a408e627396912)
(This used to be commit db2acaf46fdc38078b6b28b68909e289f6c9e0ec)

(cherry picked from commit 74c8575b3f3b90ea21ae6aa7ccd95947838af956)
(This used to be commit 8fd54bb55f0c23bd025d1719abcbe75c6a2ea8ac)

With the ctdb checkin dde9f3f006 tdb optimized out write lock checks for
write-enabled transaction. Sadly, this also removed the possibility to ever
remove dead records left over from tdb_delete calls within a transaction.

Tridge, please check this! Did dde9f3f006 have any reason beyond performance
optimizations?

Thanks,

Volker
(cherry picked from commit 3f884c4ae36f3260e63626bdd4989d9258ae6497)
(This used to be commit 1d85e0647e287d269b3f6b534da88f497d6f76c3)

used for tdb_traverse() to tdb_traverse_read().
Jeremy.
(This used to be commit e05ec3047c4fe0cc2e09a812830fc835dc35abea)

Calling tdb_traverse inside a transaction led to the transaction lock being
held indefinitely. This was caused by the tdb_transaction_lock/unlock inside
tdb_traverse: The transaction code holds the global lock at offset
TRANSACTION_LOCK. The call to tdb_transaction_lock does nothing because the
transaction_lock is already being held. tdb_transaction_unlock inside tdb_wrap
resets tdb->have_transaction_lock but does not release the kernel-level fcntl
lock. transaction_commit later on does not release that fcntl lock either,
because tdb->have_transaction_lock was already reset by tdb_transaction().

This patch does fix that problem for me. An alternative would be to make
tdb->have_transaction_lock a counter that can cope with proper nesting, maybe
in other places as well.

Volker
(This used to be commit 89543005fe2e4934b3c560c937d49304a32a7fc2)

(This used to be commit b3e60a388d338ef90540007239e88563cb9ba27a)

(This used to be commit df4efb902ec5053ae9d7c6e4fd1e21255ca66914)

(This used to be commit eb3af24926977208a8099c848a510704d2ae3524)

(This used to be commit 7077df3e2e3f171532f6a5ac87d45201736c9c11)