-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cats: add missing database locks #1787
base: master
Are you sure you want to change the base?
cats: add missing database locks #1787
Conversation
This function is not safe to use if you dont actually own the lock, but misuse should hopefully lead to a crash anyways.
aabaf91
to
c83d9a4
Compare
This is not checked in case of private connections since they are not shared automatically. It probably makes sense to also check them since they might get shared by accident (e.g. setting a pointer in jcr and then another thread accessing that jcr).
c83d9a4
to
f438920
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not happy with the amount of calls to AssertOwnership()
, especially as it looks pretty expensive. However, I don't have a great idea how to improve it right now.
I'll see if I can come up with an idea over the weekend...
@@ -828,6 +844,7 @@ void BareosDbPostgresql::SqlUpdateField(int i) | |||
|
|||
SQL_FIELD* BareosDbPostgresql::SqlFetchField(void) | |||
{ | |||
AssertOwnership(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have any idea how this will influence runtime?
SqlFetchField()
is called a lot in pretty tight loops.
Its happy-path boils down to:
- integer comparison
- nullptr check
- boolean check
- add two pointers (for array access)
- integer increment
Calling AssertOwnership()
while assuming we're on Linux, it is completly inlined, on the happy path, and having is_private_ == false
:
- boolean check
- pointer dereference
- integer equality comparison
- integer comparison
- library call to
pthread_self()
(cannot be inlined) - long integer equality comparison (always inlined from
pthread_equal()
)
I don't say this will be a performance issue. But it definitely looks like could be. Especially with the redundant check in SqlUpdateField()
above we would call AssertOwnership()
twice for each field.
@@ -800,6 +815,7 @@ uint64_t BareosDbPostgresql::SqlInsertAutokeyRecord(const char* query, | |||
|
|||
void BareosDbPostgresql::SqlUpdateField(int i) | |||
{ | |||
AssertOwnership(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SqlUpdateField()
is only called by SqlFetchField()
, so this check is redundant.
Thank you for contributing to the Bareos Project!
By default, bareos db connections get shared by multiple jobs/threads. It is of utmost importance to ensure that those shared connections only get written to/read from if the calling thread has acquired the lock.
This PR by no means ensures that this is done correctly everywhere, but the start of an ongoing process to weed out every race condition in the database code.
This PR adds some missing locks as well as assertions that locks were taken correctly at the relevant places.
Additionally it renames
bac_cursor_
tobar_cursor_
.Please check
If you have any questions or problems, please give a comment in the PR.
Helpful documentation and best practices
Checklist for the reviewer of the PR (will be processed by the Bareos team)
Make sure you check/merge the PR using
devtools/pr-tool
to have some simple automated checks run and a proper changelog record added.General
Source code quality
Tests