Multiple issues with extra_max_connections

Bug #1201377 reported by Alexey Kopytov on 2013-07-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
Status tracked in 5.7
5.1
Undecided
Unassigned
5.5
Medium
Unassigned
5.6
Medium
Unassigned
5.7
Medium
Unassigned

Bug Description

extra_max_connections is described in the MariaDB KB as follows:

"
If extra-port is <> 0 then you can connect max_connections number of normal threads + 1 extra SUPER user through the 'extra-port' TCP/IP port
"

I guess it meant to say "... you can connect extra_max_connections number of normal threads + 1 extra SUPER user through the 'extra-port' TCP/IP port".

However, unless I'm missing something, extra_max_connections + 1 extra connections for _any_ user may be allowed on extra_port. Because:

1. create_new_thread() checks against thd->scheduler->max_connections+1 (i.e. extra_max_connections in this case) in assumption that the "1 extra SUPER user connection" will be enforced later, in sql_authenticate().

2. but sql_authenticate() checks the global max_connections value (i.e. the value of max-connections rather than extra-max-connections). Which means, depending on the value of max-connections, it can either allow extra_max_connections + 1 for all users, or use max_connections for extra_port as well.

Alexey Kopytov (akopytov) wrote :

Another related issue is that fix_max_connections() (called when extra_max_connections is updated dynamically) would use the global max_connections value in the call to resize_thr_alarm().

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers