Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0(EOL), 10.1(EOL)
-
None
-
10.1.9-2
Description
Test case |
--let $trial = 100
|
|
while ($trial)
|
{
|
--connect (con1,localhost,root,,)
|
--disconnect con1
|
--dec $trial
|
}
|
--echo # All done
|
On 10.0 commit aad8667f8a4e2a26652494b29ee6c12824865ac8 the test goes almost instantly:
Spent 0.126 of 13 seconds executing testcases
|
On 10.0 commit a453a280403faef3377db0441560c57b4ae1235b it takes much much longer:
Spent 100.209 of 118 seconds executing testcases
|
Also, the complete test run on win64-release2 seems to take twice as much as it used to, ~3:30 vs 1:40.
Attachments
Issue Links
- causes
-
MDEV-8512 main.pool_of_threads fails on WIndows
-
- Closed
-
Activity
Field | Original Value | New Value |
---|---|---|
Assignee | Sergei Golubchik [ serg ] | Vladislav Vaintroub [ wlad ] |
Sprint | 10.1.9-2 [ 19 ] |
Rank | Ranked lower |
Fix Version/s | 10.0.23 [ 20401 ] | |
Fix Version/s | 10.0 [ 16000 ] | |
Fix Version/s | 10.1 [ 16100 ] | |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Closed [ 6 ] |
Workflow | MariaDB v3 [ 71184 ] | MariaDB v4 [ 149508 ] |
This is a side-effect of the fix for
MDEV-8083MTR is broken on systems with IPv6 disabled https://github.com/MariaDB/server/commit/a453a280403faef3377db0441560c57b4ae1235bThe fix makes server to listen only on IPv4 by default, rather than IPv4 + IPv6
the client tries to connect to addresses returned by getaddrinfo() , in the order in which this function returns IP addresses. So, getaddrinfo gives 2 addresses for localhost, the IPv6 and IPv4, in this order. Prior to
MDEV-8083, server was listening on both IPv4 and IPv6, this the very first attempt to connect would succeed. After theMDEV-8083fix, attempt to connect to IPv6 address fails, and the failing attempt takes some time (long time to connect to non-existing address this might be Windows specific)