On 6/23/2020 10:07 AM, Mark Reynolds wrote:
In 389 what we are seeing is that our backend txn plugins are doing unindexed searches, but I would not call it a bug.
The unindexed search is fine per se (although probably not a great idea if you want the op the plugin hooked to complete quickly).
What's not fine is that all the DB reads under that search should be done in the same transaction with strong isolation.
It's really a configuration/indexing issue. But yes, there are long running operations/txns in regards to many plugins doing a lot of things while the database is being updated in the same nested operation. Now when these internal searches are properly indexed the db lock issue completely goes away.
If missing an index were to result in poor performance, agreed -- it's a configuration issue. The server process exiting seems quite an extreme consequence.
Wondering if this is the result of an old fix for a deadlock problem (bringing the internal op under the main transaction to cure the deadlock)?
How is a regular (non-internal) unindexed search run? Surely that doesn't burn through one lock per page touched?
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
