|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
firstyear commented 5 years ago | ||
tbordaz commented 5 years ago Why ? slapi_back_get_info returns 'int'. | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
firstyear commented 5 years ago Same here int32_t please :) | ||
tbordaz commented 5 years ago This is callback from slapi_back_get_info that returns 'int' not int32_t. | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
firstyear commented 5 years ago With txn's like this, I think it's good to avoid nested txns in the future, so my question is if we are already in a txn when the function is called here, or if we really are a parent making new txns for data manipulation | ||
tbordaz commented 5 years ago Well currently this is a new interface BACK_INFO_INDEX_KEY is only used during online total init. There is no parent txn. | ||
lkrispen commented 5 years ago I think with our current txn mechanism you don't need to know if you are in a txn already, txn_init will check the txn stack in the thread and nest txns automatically. | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Bug Description:
During a total initialization the supplier builds a candidate list of the entries to send.
Because of https://fedorahosted.org/389/ticket/48755, the candidate list relies on parentid attribute.
All entries, except tombstones and suffix itself, have parentid.
There is an assumption that the first found key (i.e. '=1') contains the suffix children.
So when it finally finds the suffix key it adds its children to a leftover list rather to the candidate list.
Later idl_new_range_fetch loops for ever trying to add suffix children from leftover to candidate list.
Fix Description:
The fix consist to detect that the suffix key was not the expected one. Then to identify the suffix key and
add its children to the candidate list. So remaining key/id in the leftover array will find their parents
https://pagure.io/389-ds-base/issue/49915
Reviewed by: ?
Platforms tested: F27
Flag Day: no
Doc impact: no
int32_t ?