Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5.47, 10.1.9, 10.1.10, 5.5(EOL), 10.0(EOL), 10.1(EOL)
-
Ubuntu 14.04.3 LTS, VM with 10GB RAM
-
5.5.48-0
Description
Tested on MySQL 5.5.29 as well as MariaDB 10.0.21, bug not present. The explain returns the desired result (56 rows).
The bug is easily reproducible on MariaDB 10.1 by running the attached explain_bug.sql script on any test database. All it does is create 2 empty tables and running an explain.
The result is
ERROR 5 (HY000) at line 79 in file: '/home/tnguyen/explailn_bug.sql': Out of memory (Needed 5784 bytes)
|
MySQL error log:
2016-01-25 16:47:45 139975536690944 [ERROR] mysqld: Out of memory (Needed 5784 bytes)
|
2016-01-25 16:47:45 139975536690944 [ERROR] Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space
|
ulimit -a:
core file size (blocks, -c) 0
|
data seg size (kbytes, -d) unlimited
|
scheduling priority (-e) 0
|
file size (blocks, -f) unlimited
|
pending signals (-i) 47584
|
max locked memory (kbytes, -l) 64
|
max memory size (kbytes, -m) unlimited
|
open files (-n) 1024
|
pipe size (512 bytes, -p) 8
|
POSIX message queues (bytes, -q) 819200
|
real-time priority (-r) 0
|
stack size (kbytes, -s) 8192
|
cpu time (seconds, -t) unlimited
|
max user processes (-u) 47584
|
virtual memory (kbytes, -v) unlimited
|
file locks (-x) unlimited
|
syslog:
nothing
This bug is causing previously working ETL code to fail after a database upgrade, even though we don't have any real memory issue as it was working fine on older db versions.
Also attached the same my.cnf that I used to test on 10.0.21 and 10.1.9 & 10.1.10.
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | Confirmed [ 10101 ] |
| Fix Version/s | 5.5 [ 15800 ] | |
| Fix Version/s | 10.0 [ 16000 ] | |
| Fix Version/s | 10.1 [ 16100 ] | |
| Affects Version/s | 5.5.47 [ 20300 ] | |
| Affects Version/s | 5.5 [ 15800 ] | |
| Affects Version/s | 10.0 [ 16000 ] | |
| Affects Version/s | 10.1 [ 16100 ] | |
| Assignee | Oleksandr Byelkin [ sanja ] |
| Labels | optimizer | optimizer regression |
| Sprint | 5.5.48-0 [ 33 ] |
| Rank | Ranked higher |
| Status | Confirmed [ 10101 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Description |
Tested on MySQL 5.5.29 as well as MariaDB 10.0.21, bug not present. The explain returns the desired result (56 rows). The bug is easily reproducible on MariaDB 10.1 by running the attached explain_bug.sql script on any test database. All it does is create 2 empty tables and running an explain. The result is ERROR 5 (HY000) at line 79 in file: '/home/tnguyen/explailn_bug.sql': Out of memory (Needed 5784 bytes) MySQL error log: 2016-01-25 16:47:45 139975536690944 [ERROR] mysqld: Out of memory (Needed 5784 bytes) 2016-01-25 16:47:45 139975536690944 [ERROR] Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space ulimit -a: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 47584 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 47584 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited syslog: nothing This bug is causing previously working ETL code to fail after a database upgrade, even though we don't have any real memory issue as it was working fine on older db versions. Also attached the same my.cnf that I used to test on 10.0.21 and 10.1.9 & 10.1.10. |
Tested on MySQL 5.5.29 as well as MariaDB 10.0.21, bug not present. The explain returns the desired result (56 rows). The bug is easily reproducible on MariaDB 10.1 by running the attached explain_bug.sql script on any test database. All it does is create 2 empty tables and running an explain. The result is {noformat} ERROR 5 (HY000) at line 79 in file: '/home/tnguyen/explailn_bug.sql': Out of memory (Needed 5784 bytes) {noformat} MySQL error log: {noformat} 2016-01-25 16:47:45 139975536690944 [ERROR] mysqld: Out of memory (Needed 5784 bytes) 2016-01-25 16:47:45 139975536690944 [ERROR] Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space {noformat} ulimit -a: {noformat} core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 47584 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 47584 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited {noformat} syslog: nothing This bug is causing previously working ETL code to fail after a database upgrade, even though we don't have any real memory issue as it was working fine on older db versions. Also attached the same my.cnf that I used to test on 10.0.21 and 10.1.9 & 10.1.10. |
| Assignee | Oleksandr Byelkin [ sanja ] | Sergei Golubchik [ serg ] |
| Status | Stalled [ 10000 ] | In Review [ 10002 ] |
| Assignee | Sergei Golubchik [ serg ] | Oleksandr Byelkin [ sanja ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Fix Version/s | 5.5.48 [ 21000 ] | |
| Fix Version/s | 10.0.24 [ 21101 ] | |
| Fix Version/s | 10.1.12 [ 21502 ] | |
| Fix Version/s | 10.0 [ 16000 ] | |
| Fix Version/s | 5.5 [ 15800 ] | |
| Fix Version/s | 10.1 [ 16100 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Workflow | MariaDB v3 [ 73801 ] | MariaDB v4 [ 150032 ] |