-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Rethink closing strategy of the ThreadLocalPool optimised pgpool #10228
Conversation
Sorry I can't review this besides rubber-stamping it. This concurrency stuff is not something I'm familiar with. |
I mean, I can definitely rubber-stamp this if that's what you're after, but I suspect you want someone to actually understand what you changed, right? If yes, I'm not qualified. |
Ok I'll take the rubber-stamp then :) If there's issues, I'll fix them Re-pushed as there was a formatting issue. |
CI is passing |
great. Could you merge it @geoand ? I think Stephane mentioned going on PTO and we need the feature - this code is all disabled by default so should be low risk. |
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 trust you :)
Have been tinkering with the new pool a bit.
The main improvement is that the thredlocals and their matching List of opened pools is being treated as a single element of state, so stored together and closed as one. Before you could have some odd situations with the list being attempted to be modified during a close, or viceversa.
Should still be very efficient, however I didn't test that.