Reintroduce async logging#82516
Conversation
…dledSignals It might happen if the DateLUT global instance is destroyed before the HandledSignals global instance
|
Workflow [PR], commit [617e418] Summary: ❌
|
|
Probably related to the fact that now we don't flush the logs queue when close() is called. I'll do some checks and change it |
azat
left a comment
There was a problem hiding this comment.
I have not looked deeply, only the patch that fixes possible crashes, and this part LGTM
| throw SystemException("cannot start thread"); | ||
| FastMutex::ScopedLock l(_pData->mutex); | ||
| _pData->pRunnableTarget = pTarget; | ||
| if (pthread_create(&_pData->thread, &attributes, runnableEntry, this)) |
There was a problem hiding this comment.
And I guess we don't need ThreadStatus here? (like we have in
total_memory_tracker.
There was a problem hiding this comment.
I don't think we do, but we can add it for consistency
There was a problem hiding this comment.
I added it locally but it made things way more complicated in terms of initialization and handling. I think I'm going to avoid it for now, since these threads are not meant to do anything related to queries and so on.
7b93e84 to
f713e97
Compare
|
The CI is extremely slow and painful as of late. Failures so far:
|
98fde27
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Introduce async logging
Original PR: #80125
Addressed the issues found by #82068 and randomizes which logger is used in the CI. I expect we'll remove sync logging once async logger is battle-tested but we should keep it for now
Documentation entry for user-facing changes