Age | Commit message (Collapse) | Author | Files | Lines |
|
(cherry picked from commit 6f88c41c31271fd4b634b6393dc4ca44563a88d2)
(This used to be commit 830f99fb5d73c999bb0975828bab6e5f7537baf6)
|
|
Jeremy.
(This used to be commit 0bae1ef3de8fda5e1e2d641b14a408e627396912)
|
|
to do so may result in lost data. Fix an ifdef check, I really think we meant to check HAVE_MMAP here.
(This used to be commit 74c8575b3f3b90ea21ae6aa7ccd95947838af956)
|
|
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
(This used to be commit 3f884c4ae36f3260e63626bdd4989d9258ae6497)
|
|
This reverts commit fafb8ad2b81b9a46cf8259bedc1dca5023b06115.
This fix is not valid:
1. convert_string() is not only used for key strings but also for data.
2. Some databases use string_tdb_data() i.e. non-null-terminated strings
as keynames and others (like the one I was using), use
string_term_tdb_data(), i.e. zero-terminated key strings.
After discussion with Metze, the easiest (and proper way) to
handle this is to specify key names as "keyname\0" for databases
which use string_term_tdb_data().
Sorry for the noise...
Michael
(cherry picked from commit 17c012c4645f4e9542537c15f80d9b4e74304d11)
(This used to be commit 42c953c106b3da90e8c3452c4a246392502c200d)
|
|
This prevented all commands operating on keys (all non-traverse commands)
in tdbtool to fail with a "fetch failed" or "delete failed" message.
It seems that it fixes bug #2344 ...
Apparently this bug was introduced with 94e53472666ed in 2005.
Either nobody is using tdbtool or else tdb_find() has become
more strict about the key legth in the meantime. :-)
Michael
(This used to be commit 9be6b46f7715cdc7f77308d7613e8df73effe3c1)
|
|
used for tdb_traverse() to tdb_traverse_read().
Jeremy.
(This used to be commit bda0f03fb3fa8a7b14d4f54bee7076d691cad44f)
|
|
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 80e700e3bd73f2ffa38046bdcba7f532e25198ef)
|
|
(cherry picked from parts of commit 91d7ba5202e6c375456a42c2c6861f63c7fcfc20)
Michael
(This used to be commit 4b03f88c1ed8c1a2c1e5e7d461ca2d64a8d6a054)
|
|
(cherry picked from parts of c8947fda23eb874a7694bdee1b4de605744c2769)
Michael
(This used to be commit 77664bc482071798571096a299e7d8b190f53797)
|
|
metze
(cherry picked from parts of commit c179807165b84dd832ab64f794034960668e5957.
The changes to lib/replaces have already been merged.)
Michael
(This used to be commit 6c092918725019274cd26218168c5b551ab3c7d2)
|
|
(cherry picked from parts of commit 91133d27110ee6447dbc64f1c8d52cb90ca1a86c)
Michael
(This used to be commit f231d03e53dcf291e0cb8870e531989ab855eae0)
|
|
that.
(cherry picked from parts of commit 228dd6830eb9c91287bb3e0233d8b3a404ff3676)
Michael
(This used to be commit 7a7dcd9b1265b8f031c9a5e9c4cfa89216827a28)
|
|
(This used to be commit 92503eb60ea877a5dbf19acec7d7102fcf2923e7)
|
|
(This used to be commit eaba373747e7de5f911b25952ee396ab1bae75d9)
|
|
(This used to be commit 1a1c7954368a7f168a57f86f4f857cf70258e37a)
|
|
(This used to be commit 8c89d60924b0380231da834cd3c097b4f8cdc369)
|
|
Tridge, Jeremy, please check!
Thanks,
Volker
(This used to be commit e4f46d527411c54e8f26c05033b744c751810c32)
|
|
(This used to be commit 4f95c58040f46f343f55f9a5db2655a5e3b62c00)
|
|
(This used to be commit 625241c4773ae5c80dd0cb0c07a86aff633c1ede)
|
|
(This used to be commit 871cee04f26da97756804b38acfd366b6011dc9e)
|
|
minor fix to transaction_write_existing: tridge.
Jeremy.
(This used to be commit 874425c8f680fb2f737b46a3177b239e69302af5)
|
|
(This used to be commit 9f002eeff9bcf33a00e5641cb14338e866a17afe)
|
|
(This used to be commit c91e9c785b5bf4b0c479edf8eb33da22bf615387)
|
|
(This used to be commit 4aaf4e7e73a5c7fa97ef730fbff5c7cb12df2d6c)
|
|
this. Fixes insidious problem with order n^2 freelist merging.
Jeremy.
(This used to be commit c6609c042b128e7d63eb64cfdfb0f6b65cb59d76)
|
|
(This used to be commit 2a5c53220a5cc2b4a80fc7c6cb38e87789c5e797)
|
|
(This used to be commit e18fab269c7370a6670c56eeab60fd90feecf0b2)
|
|
(This used to be commit 223352e32372f1b055298cfc6f2770043a845e3d)
|
|
(This used to be commit 89e2984a84951373d0e93fe06d0c69c8a62bc777)
|
|
(This used to be commit fc58f2f45ab93ecea855e1dc07b6fdccce041c8d)
|
|
Jeremy.
(This used to be commit c14db81be5212dfa6fbcf8bfdcf725d7db3376ca)
|
|
Jeremy.
(This used to be commit ecc2555197860ae56726724ec824fc149d2d831c)
|
|
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.
(This used to be commit ab11c0055761e97ba32a8c3ec4fa6f8763a262cd)
|
|
an alarm sig would not terminate and could lead
to runaway smbd processes.
Thanks to Dave Daugherty @ Centrify for pointing
this out to us.
Jeremy.
(This used to be commit ef8da1698371c95495add53df81a978df709c88d)
|
|
libreplace testing.
metze
(This used to be commit 4f084efd6ac39a8347d5cfc73b727940e40150cf)
|
|
(This used to be commit 5c6c8e1fe93f340005110a7833946191659d88ab)
|
|
Guenther
(This used to be commit 579fb55b7556dc90b42f77d5fc9e9c31f34974e5)
|
|
r23977.
Michael
(This used to be commit a3506f291abfb8a9516b79c10c79841a7391651e)
|
|
(This used to be commit 4a5fa715a6af281282092644817599f79806981d)
|
|
(This used to be commit 26d1430283bd4ae8b8a84f3253e33417d509c1a4)
|
|
(This used to be commit eabe796e464e5fe10d0f4cca1362985c529f5a5b)
|
|
Michael
(This used to be commit de0ef9134650e3e7cc5b5cfec9e8dd8510bd6677)
|
|
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
(This used to be commit 24fed55d72a4922bfd3ddba61449fbae01365feb)
|
|
* 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
(This used to be commit 5b8d53dfe1872621bf28c8351d87bfc53ef6e66b)
|
|
The proper error condition is (ret == -1) instead of
(ret != number_of_byte_told_to_write).
Michael
(This used to be commit e3af95f0983e9f92c10a80ee4f15a0cd718a4728)
|
|
Michael
(This used to be commit 63c4c40cf7055ab7cf413a23e306cf209a1dd0a1)
|
|
(This used to be commit 864b3d260f3b099b1f24edf4ed0a7ed52b05f6cc)
|
|
Michael
(This used to be commit 3a2a032a44502eebdb61faf9cfdb3e54f5072514)
|
|
(This used to be commit 87c91e4362c51819032bfbebbb273c52e203b227)
|