Add client user connection limit#1137
Conversation
JelteF
left a comment
There was a problem hiding this comment.
This seems like a good solution to the described problem. A similar setting would probably be useful per database, but that doesn't need to be in this PR.
Some things that should be changed about the PR:
- Github Actions should be green (fix C warning and fix formatting)
- A test should be added (
test/test_limits.pyseems like a good place to add one) - The new option should be documented in
doc/config.md
@JelteF I believe the 3 points above have been addressed, can I get another review? Also I opened #1138 to address this issue from the database side. One question: should the values of max clients and current clients connected be added to the output of |
|
I didn't review this PR yet but I noticed that you did lots of changes in the documentation that is not related to this feature. If you want to propose a whitespace cleanup, create a separate PR. We generally use BTW, I'm fine with this feature. It is equivalent to |
Apologies about that, my editor eliminates trailing whitespace default. Will revert momentarily. |
I reverted the whitespace removal and changed the comment style to conform with the rest of the codebase. |
JelteF
left a comment
There was a problem hiding this comment.
Thanks! That looks a lot better already. I left a review just now on your other #1138 PR. Most of the feedback there should also be applied here. Other than that it looks pretty good.
I still have want to do some manual tests of both PRs though
|
@JelteF Made all of the documentation changes and added a test of the stats command in the unit tests. Also split the unit test out into 2 separate ones: one that is meant to deny a connection and one that is meant to accept a connection, I feel this is a bit cleaner. A few additional thoughts:
|
Let's keep them separate
Let's keep them as is. I don't think the better naming (because I agree it is a bit confusing now) is worth breaking backwards compatibility of the config setting names.
It's fine as is imho. |
JelteF
left a comment
There was a problem hiding this comment.
Sorry for the delay in reviewing. I think this is almost good now, some final suggested changes.
|
@JelteF Pushed a new commit that fixes a bunch of the issues the issues that you mentioned. Found that the auth pass through issue that you mentioned in #1138 applies to this PR as well. Implemented a somewhat hacky fix to this. Would appreciate your feedback on this or if you have any alternative ideas. Also expanded unit test coverage for stats users and auth pass through users. One area that isnt covered is PAM but looking through the unit tests I dont think there is any test coverage of PAM currently so I think adding that here might be out of scope for this PR though it would be very beneficial. Also I believe that the macOS failures are flaky tests but I'm not sure. I have no local dev environment for macOS so its kind of hard for me to figure out what is happening there. |
|
@JelteF Anything else I can do here to help this PR get merged? |
|
No, it's blocked on me finding some time to review PgBouncer PRs again. Busy busy. |
| if (!client->login_user_credentials->global_user) | ||
| return true; | ||
|
|
||
| if (!client->user_connection_counted) { |
There was a problem hiding this comment.
I agree this is not an elegant solution. But given the amount of counting bugs found in earlier versions, I prefer this way because this one is obviously correct and will stay correct in the future. I added a check for user_connection_counted in the decrement path too.
|
@JelteF anything else you want done with this PR before merging? |
|
I don't remember why I didn't press merge yet, maybe because CI was failing for unrelated reasons. |
Related to #1137. This PR allows the user to configure client connection limits at the database level. This prevents issues where SQL clients all connecting to a single database consume the entire connection limit defined in max_client_conn which effectively locks all other databases from being accessed.
This PR adds a user level client connection limit. I believe that currently user connections can only be limited by how many people are given connections to the database backends but there is no way to limit the number of connections to pgbouncer itself. Combined with the global connection limit this means that one user could use up all connections on the pgbouncer instance. This PR proposes a fix to this problem. Related to pgbouncer#1136 (because it partially fixes it)
Related to pgbouncer#1137. This PR allows the user to configure client connection limits at the database level. This prevents issues where SQL clients all connecting to a single database consume the entire connection limit defined in max_client_conn which effectively locks all other databases from being accessed.
This PR adds a user level client connection limit. I believe that currently user connections can only be limited by how many people are given connections to the database backends but there is no way to limit the number of connections to pgbouncer itself. Combined with the global connection limit this means that one user could use up all connections on the pgbouncer instance. This PR proposes a fix to this problem.
Related to #1136 (because it partially fixes it)