[Maria-discuss] mariadb 10.3.15 doesn't work
Hi Expert,
I encounter below issue with mariadb 10.3.15, any suggestions?
BTW, it works well with 10.3.13. # mysql -h 127.0.0.1 -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 3 Server version: 10.3.15-MariaDB Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | +--------------------+ 4 rows in set (0.105 sec)
MariaDB [(none)]> use information_schema; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A
Database changed MariaDB [information_schema]> show databases; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... ERROR 2002 (HY000): Can't connect to MySQL server on '127.0.0.1' (115) ERROR: Can't connect to the server
Thanks,
First step check your error log.
Rhys
From: Maria-discuss maria-discuss-bounces+rhys.campbell=swisscom.com@lists.launchpad.net On Behalf Of mingming1 yu Sent: 03 June 2019 11:13 To: maria-discuss@lists.launchpad.net Subject: [Maria-discuss] mariadb 10.3.15 doesn't work
Hi Expert,
I encounter below issue with mariadb 10.3.15, any suggestions?
BTW, it works well with 10.3.13. # mysql -h 127.0.0.1 -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 3 Server version: 10.3.15-MariaDB Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | +--------------------+ 4 rows in set (0.105 sec)
MariaDB [(none)]> use information_schema; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A
Database changed MariaDB [information_schema]> show databases; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... ERROR 2002 (HY000): Can't connect to MySQL server on '127.0.0.1' (115) ERROR: Can't connect to the server
Thanks,
Hi!
It's https://jira.mariadb.org/browse/MDEV-19490
The fix is already pushed, it should be in 10.3.16
On Jun 03, mingming1 yu wrote:
Hi Expert,
I encounter below issue with mariadb 10.3.15, any suggestions?
BTW, it works well with 10.3.13. # mysql -h 127.0.0.1 -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 3 Server version: 10.3.15-MariaDB Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | +--------------------+ 4 rows in set (0.105 sec)
MariaDB [(none)]> use information_schema; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A
Database changed MariaDB [information_schema]> show databases; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... ERROR 2002 (HY000): Can't connect to MySQL server on '127.0.0.1' (115) ERROR: Can't connect to the server
Thanks,
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi!
It's https://jira.mariadb.org/browse/MDEV-19490
The fix is already pushed, it should be in 10.3.16
Will the 10.3.16 come earlier as the expected 2019-06-28 release date or no?
It's a bit scary running on production now with such a simple way of generating a server segfault.
rr
Hi, Reinis!
On Jun 03, Reinis Rozitis wrote:
Hi!
It's https://jira.mariadb.org/browse/MDEV-19490
The fix is already pushed, it should be in 10.3.16
Will the 10.3.16 come earlier as the expected 2019-06-28 release date or no?
There was no plan for that, because formally we only do it for "critical security bugs" as defined here: https://mariadb.org/about/security-policy/
It's a bit scary running on production now with such a simple way of generating a server segfault.
yes, I see your point. We've replanned and the release is scheduled for the next week :)
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
On 3-6-2019 12:01, Reinis Rozitis wrote:
Hi!
It's https://jira.mariadb.org/browse/MDEV-19490
The fix is already pushed, it should be in 10.3.16
Will the 10.3.16 come earlier as the expected 2019-06-28 release date or no?
It's a bit scary running on production now with such a simple way of generating a server segfault.
It's also a bit scary that some people use this in production without testing. If there is really a simple way of getting a server segfault, than this should have come up on the test (before going into production).
It's also a bit scary that some people use this in production without testing. If there is really a simple way of getting a server segfault, than this should have come up on the test (before going into production).
It doesn't happen like that in software development - there are usually no tests before a particular bug/problem arises. Once it happens one can hope somebody will write a test for that (and add it to some continuous test framework) so it doesn’t return in future.
If you are directing it towards end-users - you can go through changelogs of every MySQL (upstream) and Mariadb (downstream) release and you'll see that if not every then every second has a major bug like crash / dataloss / corruption and what not else. So you face the same scary choices when upgrading and when not. Asking for a user to test every aspect of a complicated piece of software as rdbm is a bit unrealistic.
rr
Out of curiosity, why doesn't this release get pulled from repositories. I understand all of the rationale behind no tests until the bug hits(and agree with it), i've been using mysql since 4.06, or 3.x i believe. I've never seen a "use [database]" case a segfault. I realize information_schema is special as is performance_schema. This is just a question, not a judgement.
Best, Jeff
On Wed, Jun 5, 2019 at 4:15 AM Reinis Rozitis r@roze.lv wrote:
It's also a bit scary that some people use this in production without
testing. If
there is really a simple way of getting a server segfault, than this
should have
come up on the test (before going into production).
It doesn't happen like that in software development - there are usually no tests before a particular bug/problem arises. Once it happens one can hope somebody will write a test for that (and add it to some continuous test framework) so it doesn’t return in future.
If you are directing it towards end-users - you can go through changelogs of every MySQL (upstream) and Mariadb (downstream) release and you'll see that if not every then every second has a major bug like crash / dataloss / corruption and what not else. So you face the same scary choices when upgrading and when not. Asking for a user to test every aspect of a complicated piece of software as rdbm is a bit unrealistic.
rr
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Hi, Jeff!
On Jun 12, Jeff Dyke wrote:
Out of curiosity, why doesn't this release get pulled from repositories. I understand all of the rationale behind no tests until the bug hits(and agree with it), i've been using mysql since 4.06, or 3.x i believe. I've never seen a "use [database]" case a segfault. I realize information_schema is special as is performance_schema. This is just a question, not a judgement.
Sometimes we do pull releases. Or we can do an urgent out-of-schedule release. Or both.
Depends on when the bug was introduced and when it was discovered, how serious it is (https://mariadb.org/about/security-policy/), how many users are affected, etc.
If a regression affects lots of users and is discovered within hours after the release (it happened, may be, only once in 10 years), then we pull the release from repositories. To reduce the number of users who would be affected by it.
The first email in this thread came almost a month after 10.3.15 release. At that point it's too late to pull a release - the majority of 10.3.16 users has already installed it. Also it shows that the bug does not affect that many users, otherwise we would've got reports about it much earlier.
So, we're doing an out-of-schedule release to fix this embarassing regression, but not pulling the old release.
Btw, use information_schema; on itself does not cause a segfault, we use this statement many times in the test suite.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Thank you for the detailed response, much appreciated. I may have done something else or had database corruption on a test box b/c when i changed in the basic mysql client, that occured. Though i'm not going to stand behind that as an absolute b/c that test machine has already been destroyed.
Best, Jeff
On Thu, Jun 13, 2019 at 6:06 AM Sergei Golubchik serg@mariadb.org wrote:
Hi, Jeff!
On Jun 12, Jeff Dyke wrote:
Out of curiosity, why doesn't this release get pulled from repositories. I understand all of the rationale behind no tests until the bug hits(and agree with it), i've been using mysql since 4.06, or 3.x i believe. I've never seen a "use [database]" case a segfault. I realize information_schema is special as is performance_schema. This is just a question, not a judgement.
Sometimes we do pull releases. Or we can do an urgent out-of-schedule release. Or both.
Depends on when the bug was introduced and when it was discovered, how serious it is (https://mariadb.org/about/security-policy/), how many users are affected, etc.
If a regression affects lots of users and is discovered within hours after the release (it happened, may be, only once in 10 years), then we pull the release from repositories. To reduce the number of users who would be affected by it.
The first email in this thread came almost a month after 10.3.15 release. At that point it's too late to pull a release - the majority of 10.3.16 users has already installed it. Also it shows that the bug does not affect that many users, otherwise we would've got reports about it much earlier.
So, we're doing an out-of-schedule release to fix this embarassing regression, but not pulling the old release.
Btw, use information_schema; on itself does not cause a segfault, we use this statement many times in the test suite.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (6)
-
Jeff Dyke -
Luuk -
mingming1 yu -
Reinis Rozitis -
Rhys.Campbell＠swisscom.com -
Sergei Golubchik