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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Instead, tie them together via referencing a permanent linked list hung off the ctdb structure.
(This used to be ctdb commit a95c02da6c67dc4bd8716b75318a4188301df6f9)
It is very misleading in ctdb_persistent.c, since it is used for non-persistent
dbs...
(This used to be ctdb commit a956fa3a27106d0154a3fb46987d61c0a6b7c768)
Sometimes ctdb is termnated ifrom the initscript if the shutdown takes too long an no message is logged.
(This used to be ctdb commit d3542d43141c1548bab356fbdef34dfedb4f167f)
there are some child processes where we do not create a connection to the main daemon (switch_from_server_to_client()) because it is expensive to set up and we normally might not need to talk to the daemon at all via a domainsocket.
but we might want to still call to ctdb_ltdb_store() from such chil processes.
(This used to be ctdb commit 9e372a08c40087e6b5335aa298e94d88273566a5)
This reverts commit 11dee7f3f881494cf5089d6c69fd40e74f07e670.
Try to solve this a different way so that ctdb_ltb_store() becomes safe to use also from child context
(This used to be ctdb commit 5990fe65a9cc37933ceff15d4cb2ab3b3a0addb6)
it sometimes (for empty records) needs to be able to initiate traffic unde rhte daemon context.
This should furhter updated later to allow the use also from non-daemon context.
(This used to be ctdb commit 11dee7f3f881494cf5089d6c69fd40e74f07e670)
Everytime we give a delegation to another node we count this as one delegation.
If the same record is delegated to several nodes we count one for each node.
Everytime a record has all its delegations revoked we count this as one revoke.
(This used to be ctdb commit b098bcf8007be63889aaed640a951b0eeaa9d191)
We dont strictly need to force clients to use CTDB_FETCH_WITH_HEADER instead of CTDB_FETCH when they ask for readonly records.
Have ctdbd internally remap this internally to FETCH_WITH_HEADER and map the reply back to CTDB_FETCH_FUNC or CTDB_FETCH_WITH_HEADER_FUNC based on what the client initially asked for.
This removes the need for the client to know about the CTDB_FETCH_WITH_HEADER_FUNC function and simplifies the client code.
Clients that do not care what the header after the request is can just continue using the old CTDB_FETCH_FUNC call and ctdbd will do all the difficult stuff.
(This used to be ctdb commit 444a7bac4e9a854b06c1ad4cb36c2b58a72001fa)
This way, especially records added in the fast vacuuming runs
are deleted direclty instead of being handed back to the
repack run which will probably not hit because of the vacuum limit.
(This used to be ctdb commit ea3e640a28178ddcb85285f4efec62ccba2483d9)
Track the number of records failed to delete remotely with the
TRY_DELETE_RECORDS control.
And add a number of records left to delete locally.
(This used to be ctdb commit 536aad024d52f2c32dd397fc86294c963b91341b)
