IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
Mainly this is the svn changes :
------------------------------------------------------------------------
r23238 | tridge | 2007-05-30 01:15:49 -0700 (Wed, 30 May 2007) | 6 lines
merged transaction lock changes from ctdb
this ensures that having the global lock also implies the transaction
lock
------------------------------------------------------------------------
r22832 | tridge | 2007-05-13 18:00:06 -0700 (Sun, 13 May 2007) | 3 lines
merged the latest tdb changes from ctdb to Samba4
Jeremy.
error condition to write. This is in tdb_new_database.
Fix one call to tdb_new_database in tdb_open_ex to not
overwrite the newly propagated errno (typically ENOSPC).
Michael
* prevent infinite loops due to 0 bytes written:
try once more. if we still get 0 as return,
set errno to ENOSPC and return -1 (error)
* replace int by correct types (ssize_t and size_t).
* print a warning log message in case "written < requested to write"
usually this means, that the next call to pwrite will fail
with return value -1 and set errno accordingly.
Note that the former error condition "written != requested to write"
is not a correct error condition of write/pwrite. If this is due
to an error, a subsequent call to (p)write will reveal the cause
(typically "no space left on device" - ENOSPC).
Michael
travlocks.lock_rw for lock read/write types, it
was sometimes using it (tdb_next_lock) and
sometimes explicitly using F_WRLCK instead.
Change this to consistently use travlocks.lock_rw
only.
I'm pretty sure about this fix (else I woudn't
be checking this in :-) but tridge and Volker
please review.
Jeremy.
