Added max_sessions_for_user setting #51724

Demilivor · 2023-07-03T08:16:49Z

This change adds a limit on the maximum number of simultaneous sessions per authenticated user.

Changelog category (leave one):

New Feature

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Added max_sessions_for_user setting

robot-ch-test-poll4 · 2023-07-03T08:22:09Z

This is an automated comment for commit 7e9e0ac with description of existing statuses. It's updated for the latest CI running
The full report is available here
The overall status of the commit is 🔴 failure

Check name	Description	Status
AST fuzzer	Runs randomly generated queries to catch program errors. The build type is optionally given in parenthesis. If it fails, ask a maintainer for help	🟢 success
CI running	A meta-check that indicates the running CI. Normally, it's in success or pending state. The failed status indicates some problems with the PR	🟢 success
ClickHouse build check	Builds ClickHouse in various configurations for use in further steps. You have to fix the builds that fail. Build logs often has enough information to fix the error, but you might have to reproduce the failure locally. The cmake options can be found in the build log, grepping for cmake. Use these options and follow the general build process	🟢 success
Compatibility check	Checks that clickhouse binary runs on distributions with old libc versions. If it fails, ask a maintainer for help	🟢 success
Docker image for servers	The check to build and optionally push the mentioned image to docker hub	🟢 success
Docs Check	Builds and tests the documentation	🟢 success
Fast test	Normally this is the first check that is ran for a PR. It builds ClickHouse and runs most of stateless functional tests, omitting some. If it fails, further checks are not started until it is fixed. Look at the report to see which tests fail, then reproduce the failure locally as described here	🟢 success
Flaky tests	Checks if new added or modified tests are flaky by running them repeatedly, in parallel, with more randomization. Functional tests are run 100 times with address sanitizer, and additional randomization of thread scheduling. Integrational tests are run up to 10 times. If at least once a new test has failed, or was too long, this check will be red. We don't allow flaky tests, read the doc	🟢 success
Install packages	Checks that the built packages are installable in a clear environment	🟢 success
Integration tests	The integration tests report. In parenthesis the package type is given, and in square brackets are the optional part/total tests	🟢 success
Mergeable Check	Checks if all other necessary checks are successful	🟢 success
Performance Comparison	Measure changes in query performance. The performance test report is described in detail here. In square brackets are the optional part/total tests	🟢 success
Push to Dockerhub	The check for building and pushing the CI related docker images to docker hub	🟢 success
SQLancer	Fuzzing tests that detect logical bugs with SQLancer tool	🟢 success
Sqllogic	Run clickhouse on the sqllogic test set against sqlite and checks that all statements are passed	🟢 success
Stateful tests	Runs stateful functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	🟢 success
Stateless tests	Runs stateless functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	🟢 success
Stress test	Runs stateless functional tests concurrently from several clients to detect concurrency-related errors	🟢 success
Style Check	Runs a set of checks to keep the code style clean. If some of tests failed, see the related log from the report	🟢 success
Unit tests	Runs the unit tests for different release types	🟢 success
Upgrade check	Runs stress tests on server version from last release and then tries to upgrade it to the version from the PR. It checks if the new server can successfully startup without any errors, crashes or sanitizer asserts	🔴 failure

rschu1ze · 2023-07-17T12:27:16Z

My understanding is that the existing server parameter max_connections (default: 1024) already provides sufficient protection against DoS, independently if

the users are unknown/untrusted and have public credentials, e.g. user/password "default/default", or
the users are known and have "private" credentials (e.g. "denis"/"12345!@#$%").

The subject of protection is the server itself.

This PR aims to make this protection more fine-granular which will be handy for "untrusted" public credentials. In more detail, it can prevent the case that a single untrusted user is able to flood the server with hundreds of connections at the detriment of other (e.g. trusted) users that behave normally. Th is is different from max_connections as the subject of protection are other users.

docs/en/operations/settings/query-complexity.md

src/Core/Settings.h

src/Interpreters/SessionTracker.h

src/Interpreters/SessionTracker.cpp

src/Interpreters/Context.cpp

rschu1ze · 2023-07-17T14:09:50Z

src/Access/ContextAccess.cpp

-    enabled_quota = access_control->getEnabledQuota(
-        *params.user_id, user_name, roles_info->enabled_roles, params.address, params.forwarded_address, params.quota_key);
+
+    /// TCP connection handler receives quota key after session creation


I don't really understand the changes around the quota_key. How is it related to the session tracking?

I'm not sure if my solution is the best, but I haven't found a better and simpler solution to not change the current TCP protocol and make both client and server work without errors.
If you have better ideas, I will be happy to implement them.

During a session between client and server, the client assumes that there should be no errors on the server side after the server has replied Hello.
However, with the addition of the max_sessions_per_user constraint, throwing an error after server hello is now possible. To get max_sessions_per_user we need to reach the profile settings, and to do that we need to create a session context.
Creating a session context and creating a quota without a quota key can throw exception.

To better understand the problem, I have created attached images.
I hope they will make it easier to understand.

Thanks for the detailed explanation and the figures, I understood the problem now 😄

I am not an expert with the TCP protocol, but the current solution looks fine to me (not great but also not terrible) - we can go with it. My main question at this point is about this assumption:

During a session between client and server, the client assumes that there should be no errors on the server side after the server has replied Hello.

That's interesting. What happens exactly on the client? Does the connection abruptly end?

I see that there is a handler for exceptions: sendException(). Just curious, would it be possible to use this to send an exception after "Hello" to the client?

That's interesting. What happens exactly on the client? Does the connection abruptly end?

Server closes connection.
If exception happens after hello received from server client tries to send quota key if it has it. Usually server doesn't have time to close the connection while the client is sending quota key, this step passes (Client and server are on the same computer).
If the client was in interactive mode then it waits for query to enter.
After client has an query then it tries to send it to the server. Client detects that connection is closed by Connection::ping and doesn't print any error (client does not read exception code at all), and finally client tries to reconnect and reauthenticate.

I see that there is a handler for exceptions: sendException(). Just curious, would it be possible to use this to send an exception > after "Hello" to the client?

Yes, but client doesn't read the socket data after receiving hello from server, because it does not expect an error.

src/Interpreters/Context.cpp

Demilivor · 2023-07-17T23:56:24Z

Most of the core team was on an offsite meeting last week. I'll take a look.

Thank you for the thoughtful review!

My understanding is that the existing server parameter max_connections (default: 1024) already provides sufficient protection against DoS, independently if

the users are unknown/untrusted and have public credentials, e.g. user/password "default/default", or

the users are known and have "private" credentials (e.g. "denis"/"12345!@#$%").

The subject of protection is the server itself.

This PR aims to make this protection more fine-granular which will be handy for "untrusted" public credentials. In more detail, it can prevent the case that a single untrusted user is able to flood the server with hundreds of connections at the detriment of other (e.g. trusted) users that behave normally. Th is is different from max_connections as the subject of protection are other users.

You're getting the right idea.
PR adds a limit on the maximum number of simultaneous connections on some users,
This is an additional protection that is not enabled by default and should not hurt existing ClickHouse clients.
It can cover this use-case:

There are 4 analysts in the company, they use one clickhouse account, there should not be more than 4 simultaneous connections, in case of the 5th connection, it should be immediately disabled.

Session Tracker currently records not only the number of connections, but also information about connections, perhaps in the future it will be possible to create a new system table System.ActiveSessions, it will contain all information about all current connections in the system. It is not very convenient to use Session Log for this purpose.

docs/en/operations/settings/query-complexity.md

src/Interpreters/Context.cpp

rschu1ze · 2023-07-18T07:18:47Z

Session Tracker currently records not only the number of connections, but also information about connections, perhaps in the future it will be possible to create a new system table System.ActiveSessions, it will contain all information about all current connections in the system. It is not very convenient to use Session Log for this purpose.

I generally like this idea 👍 ... but before going ahead and implementing it, I recommend to first discuss the system table fields in an RFC issue on GitHub.

src/Interpreters/Session.cpp

src/Interpreters/SessionTracker.cpp

src/Interpreters/Session.cpp

rschu1ze · 2023-07-18T08:32:16Z

src/Access/ContextAccess.cpp

-    enabled_quota = access_control->getEnabledQuota(
-        *params.user_id, user_name, roles_info->enabled_roles, params.address, params.forwarded_address, params.quota_key);
+
+    /// TCP connection handler receives quota key after session creation


Thanks for the detailed explanation and the figures, I understood the problem now 😄

I am not an expert with the TCP protocol, but the current solution looks fine to me (not great but also not terrible) - we can go with it. My main question at this point is about this assumption:

During a session between client and server, the client assumes that there should be no errors on the server side after the server has replied Hello.

That's interesting. What happens exactly on the client? Does the connection abruptly end?

I see that there is a handler for exceptions: sendException(). Just curious, would it be possible to use this to send an exception after "Hello" to the client?

Demilivor · 2023-07-18T22:51:19Z

That's interesting. What happens exactly on the client? Does the connection abruptly end?

Server closes connection.
If exception happens after hello received from server client tries to send quota key if it has it. Usually server doesn't have time to close the connection while the client is sending quota key, this step passes (Client and server are on the same computer).
If the client was in interactive mode then it waits for query to enter.
After client has an query then it tries to send it to the server. Client detects that connection is closed by Connection::ping and doesn't print any error (client does not read exception code at all), and finally client tries to reconnect and reauthenticate.

I see that there is a handler for exceptions: sendException(). Just curious, would it be possible to use this to send an exception > after "Hello" to the client?

Yes, but client doesn't read the socket data after receiving hello from server, because it does not expect an error.

Demilivor · 2023-07-18T23:18:41Z

I generally like this idea 👍 ... but before going ahead and implementing it, I recommend to first discuss the system table fields in an RFC issue on GitHub.

Of course we will create RFC issue if there is a need to create such a table, but at the moment there is no immediate need.

tavplubix · 2023-07-19T13:36:38Z

src/Interpreters/Session.cpp

+    session_tracker_handle = session_context->getSessionTracker().trackSession(
+        *user_id,
+        { session_name_ },
+        session_context->getSettingsRef().max_sessions_for_user);


Can a user update the value of max_sessions_for_user in the session_context by executing a SET query, for example?

Yes, but Behaviour will not be oblivious for user,
SET sets changes in current session, but it will not have effect, because max_sessions_for_user value is taken from user profile, not session:

// in profile we have max_sessions_for_user = 0 Client_1 (user Alice): SET max_sessions_for_user = 1 // changes value for client_1 only SELECT value FROM system.settings WHERE name="max_sessions_for_user" // return 1 Client 2 (user Alice): SELECT value FROM system.settings WHERE name="max_sessions_for_user" // return 0 Client 3 (user Alice): // connections count per user (3) already SET max_sessions_for_user = 1 // active session willl continue.

So it looks like a bug to me. This bug can be applied to other settings from profile without contraints.

This SQL looks like working:

ALTER SETTINGS PROFILE <dynamic_non_readonly_profile> SETTINGS max_sessions_for_user = 1

It will not close active sessions, but at least it will not allow to start new sessions.

I would certainly throw exception when trying to set up any settings taken from the profile for a session, but during quick looking into the code of how SET work and got no easy solution. I would create an separate issue for that and investigate the problem more thoughtful.

because max_sessions_for_user value is taken from user profile, not session

No, it's taken from session_context:
https://github.com/ClickHouse/ClickHouse/blob/d3e08a1e2a91cd4bef08b8270e5e68d05332a770/src/Interpreters/Session.cpp#L470

You probably mean that it's a new session_context that was just created and the user could not modify it. But it's not true for named http sessions because NamedSessionsStorage may return an existing session that was already in use, so the setting could be modified:
https://github.com/ClickHouse/ClickHouse/blob/d3e08a1e2a91cd4bef08b8270e5e68d05332a770/src/Interpreters/Session.cpp#L443-L444

In the case of a named session, if session_context was already created, It is possible that max_sessions_for_user will have an old value:
https://github.com/ClickHouse/ClickHouse/blob/d3e08a1e2a91cd4bef08b8270e5e68d05332a770/src/Interpreters/Session.cpp#L458-L459

So, yes, it looks like a problem in this case:

ALTER SETTINGS PROFILE ALICE_PROFILE max_sessions_for_user = 100 User Alice started session_id_1 // session lifetime is 1000, max_session_per_user = 100 User Alice started session_id_2 // session lifetime is 1000, max_session_per_user = 100 User Alice started session_id_3 // session lifetime is 1000, max_session_per_user = 100 ALTER SETTINGS PROFILE ALICE_PROFILE max_sessions_for_user = 1 User Alice finished session_id_3 // named session is not deleted and context remains valid with max_session_per_user = 100 User Alice started session_id_3 // existing context was reused with max_session_per_user = 100

Calling new_session_context->setUser(*user_id) always before reading max_sessions_for_user will fix the issue.
setUser is quite a complicated operation, do you know a better way to get the max_sessions_for_user value?

Calling new_session_context->setUser(*user_id) always before reading max_sessions_for_user will fix the issue.

And will break SET queries (because it will overwrite all the settings with the user's defaults, not only max_sessions_for_user)

setUser is quite a complicated operation, do you know a better way to get the max_sessions_for_user value?

I don't know. We can take something from the implementation of setUser, maybe smth like access->getDefaultProfileInfo()->settings.max_sessions_for_user will work. Or we can save the value in NamedSessionData when creating a session. Or we can forbid changing the setting (see Context::setSettings and Context::recalculateAccessRightsIfNeeded)

Thanks for the explanation.

Just pushed an update that should forbid using SET max_sessions_for_user = 10 and several other parameters that shouldn't be updated by SET query or SETTINGS like

clickhouse-client -q "select 1 SETTINGS max_sessions_for_user = 1" // error Received exception from server (version 23.7.1): Code: 164. DB::Exception: Received from localhost:9000. DB::Exception: Setting max_sessions_for_user is not allowed to be set by query. (READONLY) (query: select 1 SETTINGS max_sessions_for_user = 2)

ALTER SETTINGS PROFILE works fine.

clickhouse-client -q "create profile my_profile" clickhouse-client -q "ALTER SETTINGS PROFILE 'my_profile' SETTINGS max_sessions_for_user = 2"

I removed settings source restrictions from SettingsConstraints.cpp for other parameters, and left just for max_sessions_for_user just to not accidentally break something. This pool request is already big.

src/Interpreters/SessionTracker.cpp

tavplubix · 2023-07-19T13:47:25Z

src/Interpreters/Session.cpp

+    session_tracker_handle = session_context->getSessionTracker().trackSession(
+        *user_id,
+        { session_name_ },
+        session_context->getSettingsRef().max_sessions_for_user);


Hm, seems like it will count one named http session multiple times. Please add a test with named http sessions (see session_id parameter)

I will add a test with different sesssion IDs, but this should not be an issue because session id must be unique for all sessions on server.

I got this error, if i try to use the same session id for HTTP:

ClickHouse HTTP server returned 500 Internal Server Error: Code: 373. DB::Exception: Session 1 is locked by a concurrent client. (SESSION_IS_LOCKED) (version 23.7.1.1)

Done (Test added)

The tricky part is that named http sessions can be reused. Of course, it's not allowed to use the same session concurrently, but it's totally fine to use it sequentially from different http requests. A new session will not be created for each request, the old one will be reused instead.

I've just tested it locally, and found that it counts an http session only if there's a running query in this session. So it's possible to open an unlimited number of named http sessions (max_sessions_for_user = 2):

   ~/ch/test  echo "select 1" | curl -X POST "http://localhost:8123/?user=maxsessions&session_id=1" -d @-  ✔ 1    ~/ch/test  echo "select 1" | curl -X POST "http://localhost:8123/?user=maxsessions&session_id=2" -d @-  ✔ 1    ~/ch/test  echo "select 1" | curl -X POST "http://localhost:8123/?user=maxsessions&session_id=3" -d @-  ✔ 1    ~/ch/test  echo "select 1" | curl -X POST "http://localhost:8123/?user=maxsessions&session_id=4" -d @-  ✔ 1    ~/ch/test  echo "select 1" | curl -X POST "http://localhost:8123/?user=maxsessions&session_id=5" -d @-  ✔ 1

(now there are 5 sessions, they will be closed after default_session_timeout seconds)

But it will not be possible to use more than 2 sessions concurrently anyway, so maybe it's fine

Hm, no, it's possible if you update the setting with a SET query: https://pastila.nl/?0120fcc0/a41fe96d1a48546e4a4939fec4fc1c7a

Confirm this issue. I'm going to fix it in the next update of this PR.

A simple uncoditional call to new_session_context->setUser(*user_id) in makeSessionContext for named sessions fixes the issue (in my old code not upmerged with master), But I'm not sure if there are any pitfalls I haven't considered.

I got several merge conflicts with master and can't update the code right now. I hope to finish the update on Monday if I do not meet other issues.

A simple uncoditional call to new_session_context->setUser(*user_id) in makeSessionContext for named sessions fixes the issue

See #51724 (comment)

This issue is no longer actual, because SET for max_sessions_for_user is prohibited now.

A similar case with ALTER SETTINGS PROFILE works fine. See the test tests/queries/0_stateless/02832_alter_max_sessions_for_user.sh

tavplubix · 2023-07-20T14:17:14Z

There's a minor usability issue:

Create a user with <max_sessions_for_user>2</max_sessions_for_user>
Connect to the server with clickhouse-client in interactive mode (starts a session)
Run another instance of interactive clickhouse-client. If will fail to load suggestions (due to the limitation on concurrent sessions) but then will continue working as usual:

ClickHouse client version 23.7.1.1.
Connecting to localhost:9000 as user maxsessions.
Connected to ClickHouse server version 23.7.1 revision 54464.

Warnings:
 * Server was built with sanitizer. It will work slowly.
 * Server logging level is set to 'test' and performance is degraded. This cannot be used in production.
 * Some obsolete setting is changed. Check 'select * from system.settings where changed' and read the changelog.

Cannot load data for command line suggestions: Code: 700. DB::Exception: Received from localhost:9000. DB::Exception: User 5eb5f051-64a4-19bc-ff75-494154bf67a9 has overflown session count 2. () (version 23.7.1.1)
dell9510 :) select 1

SELECT 1

Query id: e860678a-650c-499d-8852-d1c44f3cd06e

┌─1─┐
│ 1 │
└───┘

1 row in set. Elapsed: 0.002 sec. 

dell9510 :)

Demilivor · 2023-07-20T21:53:19Z

There's a minor usability issue:

Create a user with <max_sessions_for_user>2</max_sessions_for_user>

Connect to the server with clickhouse-client in interactive mode (starts a session)

Run another instance of interactive clickhouse-client. If will fail to load suggestions (due to the limitation on concurrent sessions) but then will continue working as usual:
ClickHouse client version 23.7.1.1.
Connecting to localhost:9000 as user maxsessions.
Connected to ClickHouse server version 23.7.1 revision 54464.

Warnings:
 * Server was built with sanitizer. It will work slowly.
 * Server logging level is set to 'test' and performance is degraded. This cannot be used in production.
 * Some obsolete setting is changed. Check 'select * from system.settings where changed' and read the changelog.

Cannot load data for command line suggestions: Code: 700. DB::Exception: Received from localhost:9000. DB::Exception: User 5eb5f051-64a4-19bc-ff75-494154bf67a9 has overflown session count 2. () (version 23.7.1.1)
dell9510 :) select 1

SELECT 1

Query id: e860678a-650c-499d-8852-d1c44f3cd06e

┌─1─┐
│ 1 │
└───┘

1 row in set. Elapsed: 0.002 sec. 

dell9510 :) 

This is a known issue. I added a comment for this issue. The client should work fine, but without receiving suggestions for connection.
I think we should create a new issue to fix this after this PR.

I see two main ways of fixing this:

Somehow indicate the suggestion connection to let the server know that this connection should not be counted.
If the suggestion connection fails, try to get the suggestion on the main connection.

src/Common/SettingsChanges.h

Demilivor · 2023-07-27T08:43:20Z

The style check failed in files I did not change:

https://s3.amazonaws.com/clickhouse-test-reports/51724/deabacfc15e7ab8b08508c1e6a0c4ab03574511f/style_check/style_output.txt

/ClickHouse/src/Processors/Formats/Impl/Parquet/Write.cpp:758:                N(UInt8 , Int32Type);
/ClickHouse/src/Processors/Formats/Impl/Parquet/Write.cpp:764:        case TypeIndex::Int16  : N(Int16 , Int32Type); break;
/ClickHouse/src/Processors/Formats/Impl/Parquet/Write.cpp:765:        case TypeIndex::Int32  : N(Int32 , Int32Type); break;
/ClickHouse/src/Processors/Formats/Impl/Parquet/Write.cpp:766:        case TypeIndex::Int64  : N(Int64 , Int64Type); break;
/ClickHouse/src/Processors/Formats/Impl/Parquet/Write.cpp:769:        case TypeIndex::Enum16:     N(Int16 , Int32Type); break;
/ClickHouse/src/Processors/Formats/Impl/Parquet/Write.cpp:771:        case TypeIndex::Date32:     N(Int32 , Int32Type); break;
/ClickHouse/src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:306:                types(T::INT32, C::UINT_8 , int_type(8 , false));
/ClickHouse/src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:312:        case TypeIndex::Int8:   types(T::INT32, C::INT_8  , int_type(8 , true)); break;
/ClickHouse/src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:313:        case TypeIndex::Int16:  types(T::INT32, C::INT_16 , int_type(16, true)); break;
/ClickHouse/src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:322:        case TypeIndex::Enum8:    types(T::INT32, C::INT_8  , int_type(8 , true)); break; //  Int8
/ClickHouse/src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:323:        case TypeIndex::Enum16:   types(T::INT32, C::INT_16 , int_type(16, true)); break; //  Int16
/ClickHouse/src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:395:        case TypeIndex::Decimal32:  decimal(4 , getDecimalPrecision(*type), getDecimalScale(*type)); break;
/ClickHouse/src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:396:        case TypeIndex::Decimal64:  decimal(8 , getDecimalPrecision(*type), getDecimalScale(*type)); break;
^ There is bad punctuation: whitespace before comma. You should write it like this: 'Hello, world!'

tavplubix · 2023-07-27T09:22:36Z

It was accidentally broken in master due to a race condition between #49367 and #52549

It's fixed in #52647, please update your branch

tavplubix · 2023-07-31T12:38:49Z

Upgrade check (asan) - #52540

Demilivor · 2023-07-31T22:56:34Z

Created and issue to fix this: #51724 (comment) #52843

tavplubix · 2023-08-01T17:02:14Z

@Demilivor, the new tests are flaky, please take a look: https://s3.amazonaws.com/clickhouse-test-reports/0/1b2e4d3ebd7a51bd528f7bb15167453180832865/integration_tests__asan__[1_6].html

alexey-milovidov · 2023-08-01T17:51:36Z

@tavplubix, we have a "fearless reverting" policy - if a test is flaky - revert the feature.

Demilivor · 2023-08-02T00:43:37Z

I apologize,

This test was my first integration test for ClickHouse,
when I created this test I didn't know about the possibility of running tests in parallel and test reordering.
This test has always performed without any error on the my machine.

I have removed the dependency on sleep and test execution order in this pool request
#52897

This comment was marked as outdated.

Sign in to view

qoega added the can be tested Allows running workflows for external contributors label Jul 3, 2023

robot-ch-test-poll4 added the pr-feature Pull request with new product feature label Jul 3, 2023

This comment was marked as outdated.

Sign in to view

rschu1ze self-assigned this Jul 17, 2023

This comment was marked as outdated.

Sign in to view

rschu1ze reviewed Jul 17, 2023

View reviewed changes

Demilivor force-pushed the ADQM-939 branch from ae07e24 to abd645b Compare July 18, 2023 05:59

rschu1ze reviewed Jul 18, 2023

View reviewed changes

Demilivor changed the title ~~Added max_sessions_per_user setting~~ Added max_sessions_for_user setting Jul 19, 2023

rschu1ze approved these changes Jul 19, 2023

View reviewed changes

tavplubix reviewed Jul 19, 2023

View reviewed changes

src/Interpreters/SessionTracker.cpp Outdated Show resolved Hide resolved

tavplubix reviewed Jul 19, 2023

View reviewed changes

Demilivor force-pushed the ADQM-939 branch from bf0b2b6 to d3e08a1 Compare July 20, 2023 00:50

tavplubix self-assigned this Jul 20, 2023

Demilivor force-pushed the ADQM-939 branch from 3c6cdf2 to af2c684 Compare July 24, 2023 11:00

rschu1ze reviewed Jul 24, 2023

View reviewed changes

src/Common/SettingsChanges.h Outdated Show resolved Hide resolved

Demilivor force-pushed the ADQM-939 branch 2 times, most recently from 3790f89 to deabacf Compare July 27, 2023 02:08

Demilivor force-pushed the ADQM-939 branch from 4e9de23 to e93132f Compare July 28, 2023 02:35

Implemented max sessions for user

e58b3cf

Demilivor force-pushed the ADQM-939 branch from dc879ca to e58b3cf Compare July 30, 2023 22:09

Demilivor added 2 commits July 31, 2023 13:43

Merge branch 'master' into ADQM-939

2c07607

Merge branch 'master' into ADQM-939

7e9e0ac

tavplubix approved these changes Jul 31, 2023

View reviewed changes

tavplubix merged commit 7359a81 into ClickHouse:master Jul 31, 2023
277 of 279 checks passed

rkozlo mentioned this pull request Sep 7, 2023

max_concurrent_queries_for_user for initial user #52344

Open

Added max_sessions_for_user setting #51724

Added max_sessions_for_user setting #51724

Conversation

Demilivor commented Jul 3, 2023 • edited

Changelog category (leave one):

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

This comment was marked as outdated.

robot-ch-test-poll4 commented Jul 3, 2023 • edited by robot-ch-test-poll

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

rschu1ze commented Jul 17, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Demilivor commented Jul 17, 2023

rschu1ze commented Jul 18, 2023

Choose a reason for hiding this comment

Demilivor commented Jul 18, 2023

Demilivor commented Jul 18, 2023

Choose a reason for hiding this comment

Demilivor Jul 19, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tavplubix Jul 21, 2023 • edited

Choose a reason for hiding this comment

Demilivor Jul 24, 2023 • edited

Choose a reason for hiding this comment

Demilivor Jul 25, 2023 • edited

Choose a reason for hiding this comment

tavplubix Jul 19, 2023 • edited

Choose a reason for hiding this comment

Demilivor Jul 20, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tavplubix commented Jul 20, 2023

Demilivor commented Jul 20, 2023

Demilivor commented Jul 27, 2023

tavplubix commented Jul 27, 2023

tavplubix commented Jul 31, 2023

Demilivor commented Jul 31, 2023

tavplubix commented Aug 1, 2023

alexey-milovidov commented Aug 1, 2023

Demilivor commented Aug 2, 2023

Demilivor commented Jul 3, 2023 •

edited

robot-ch-test-poll4 commented Jul 3, 2023 •

edited by robot-ch-test-poll

rschu1ze commented Jul 17, 2023 •

edited

Demilivor Jul 19, 2023 •

edited

tavplubix Jul 21, 2023 •

edited

Demilivor Jul 24, 2023 •

edited

Demilivor Jul 25, 2023 •

edited

tavplubix Jul 19, 2023 •

edited

Demilivor Jul 20, 2023 •

edited