[Maria-discuss] 10.3.x: unknown variable 'innodb_support_xa=1'
unknown variable 'innodb_support_xa=1' would you funny guys consider things like deperectaion warnings in previous releases or at least offer an option to change all these fucking "i don't know a option because it was removed or you did not compile something in and hence i refuse to start the server" to warnings?
On Mon, Sep 2, 2019 at 5:43 PM Reindl Harald <h.reindl@thelounge.net> wrote:
unknown variable 'innodb_support_xa=1'
would you funny guys consider things like deperectaion warnings in previous releases
A deprecation warning was added in the MariaDB Server 10.2.2, well before it was Generally Available. That said, maybe there is a nontrivial amount of users who skipped the 10.2 release and upgraded straight from 10.1 to 10.3.
or at least offer an option to change all these fucking "i don't know a option because it was removed or you did not compile something in and hence i refuse to start the server" to warnings?
That we do if you specify the loose_ prefix to the options. With best regards, Marko Mäkelä Lead Developer InnoDB MariaDB Corporation
Am 02.09.19 um 17:09 schrieb Marko Mäkelä:
On Mon, Sep 2, 2019 at 5:43 PM Reindl Harald <h.reindl@thelounge.net> wrote:
unknown variable 'innodb_support_xa=1'
would you funny guys consider things like deperectaion warnings in previous releases
A deprecation warning was added in the MariaDB Server 10.2.2, well before it was Generally Available. That said, maybe there is a nontrivial amount of users who skipped the 10.2 release and upgraded straight from 10.1 to 10.3.
come on and show me! [root@localhost:~]$ cat mysql_error.log 2019-09-02 17:11:43 139645497730816 [Note] /usr/libexec/mysqld (initiated by: unknown): Normal shutdown 2019-09-02 17:11:43 139645073479424 [Note] InnoDB: FTS optimize thread exiting. 2019-09-02 17:11:43 139645497730816 [Note] Event Scheduler: Purging the queue. 0 events 2019-09-02 17:11:43 139645498156800 [Note] Error reading relay log event: slave SQL thread was killed 2019-09-02 17:11:43 139645498156800 [Note] Slave SQL thread exiting, replication stopped in log 'bin.002679' at position 49489 2019-09-02 17:11:43 139645498464000 [Note] Slave I/O thread exiting, read up to log 'bin.002679', position 49489 2019-09-02 17:11:43 139645497730816 [Note] InnoDB: Starting shutdown... 2019-09-02 17:11:45 139645497730816 [Note] InnoDB: Shutdown completed; log sequence number 201835120033 2019-09-02 17:11:45 139645497730816 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" 2019-09-02 17:11:45 139645497730816 [Note] /usr/libexec/mysqld: Shutdown complete 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Uses event mutexes 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Compressed tables use zlib 1.2.11 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Using Linux native AIO 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Number of pools: 1 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Using SSE2 crc32 instructions 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Initializing buffer pool, total size = 64M, instances = 1, chunk size = 64M 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Completed initialization of buffer pool 2019-09-02 17:11:45 139893416630016 [Note] InnoDB: page_cleaner coordinator priority: -20 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Highest supported file format is Barracuda. 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: 128 out of 128 rollback segments are active. 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Creating shared tablespace for temporary tables 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Waiting for purge to start 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: 5.7.27 started; log sequence number 201835120033 2019-09-02 17:11:46 139893275596544 [Note] InnoDB: Loading buffer pool(s) from /Volumes/dune/mysql/mysql_dbmail/ib_buffer_pool 2019-09-02 17:11:46 139893275596544 [Note] InnoDB: Cannot open '/Volumes/dune/mysql/mysql_dbmail/ib_buffer_pool' for reading: No such file or directory 2019-09-02 17:11:46 139893743717888 [Note] Server socket created on IP: '0.0.0.0'. 2019-09-02 17:11:46 139893743717888 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.2.26-MariaDB' socket: '/var/lib/mysql/mysqld_dbmail.sock' port: 3307 thelounge 2019-09-02 17:11:46 139893708191488 [Note] Slave SQL thread initialized, starting replication in log 'bin.002679' at position 49489, relay log './mysql-relay-bin.983139' position: 549 2019-09-02 17:11:46 139893708498688 [Note] Slave I/O thread: connected to master 'replication@c*********:3307',replication started in log 'bin.002679' at position 49489 [root@localhost:~]$
On 02/09/2019 17:13, Reindl Harald wrote:
A deprecation warning was added in the MariaDB Server 10.2.2, well before it was Generally Available. That said, maybe there is a nontrivial amount of users who skipped the 10.2 release and upgraded straight from 10.1 to 10.3. come on and show me!
The way i understand Marko's sentence the deprecation warning was in 10.2 and only 10.2, since you skipped over directly to 10.3 it's to late for the warning the variable is goen
Am 02.09.19 um 17:18 schrieb Benoit Plessis:
On 02/09/2019 17:13, Reindl Harald wrote:
A deprecation warning was added in the MariaDB Server 10.2.2, well before it was Generally Available. That said, maybe there is a nontrivial amount of users who skipped the 10.2 release and upgraded straight from 10.1 to 10.3. come on and show me!
The way i understand Marko's sentence the deprecation warning was in 10.2 and only 10.2, since you skipped over directly to 10.3 it's to late for the warning
bullshit the part you skipped in your quote contains clearly "Version: '10.2.26-MariaDB'" and is a full mysqld log (cleaned before restart) with 'innodb_support_xa=1' in the config
Hi Reindl, After reading the recent thread on systemd devel ML (/etc/fstab obsolete?) I kind of find your tone a bit inappropriate. May I suggest you to try to start by applying your advice to yourself. This is clearly not a
good start for a discussion
https://lists.freedesktop.org/archives/systemd-devel/2019-August/043349.html Reindl Harald <h.reindl@thelounge.net>, 02/09/2019 – 17:20:36 (+0200):
bullshit
the part you skipped in your quote contains clearly "Version: '10.2.26-MariaDB'" and is a full mysqld log (cleaned before restart) with 'innodb_support_xa=1' in the config Maybe giving us the version you are upgrading from would have been a better starting point.
Anyway, there maybe some useful information here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920608 Marko, I believe we can expect these kinds of deprecation with people upgrading from Debian Stretch to Buster. Regards, Faustin
Am 02.09.19 um 18:05 schrieb Faustin Lammler:
After reading the recent thread on systemd devel ML (/etc/fstab obsolete?) I kind of find your tone a bit inappropriate. May I suggest you to try to start by applying your advice to yourself.
that stupid behavior of mariadb was pointed out often enough
This is clearly not a
good start for a discussion
https://lists.freedesktop.org/archives/systemd-devel/2019-August/043349.html
Reindl Harald <h.reindl@thelounge.net>, 02/09/2019 – 17:20:36 (+0200):
bullshit
the part you skipped in your quote contains clearly "Version: '10.2.26-MariaDB'" and is a full mysqld log (cleaned before restart) with 'innodb_support_xa=1' in the config Maybe giving us the version you are upgrading from would have been a better starting point.
maybe read what i wrote instead cut down my post by the first line would be a god start too or simply shut up when you are too lazy read a log starting with "Normal shutdown" and ending with "Version: '10.2.26-MariaDB'" leaded by "come on and show me!" would be a good start! * one pretends 10.2 has a deprecation warning * i repsoned with "show me" and a full log of a recent 10.2 restart * you come up with "since you skipped over directly to 10.3" seriously? ----------- Am 02.09.19 um 17:09 schrieb Marko Mäkelä:
On Mon, Sep 2, 2019 at 5:43 PM Reindl Harald <h.reindl@thelounge.net> wrote:
unknown variable 'innodb_support_xa=1'
would you funny guys consider things like deperectaion warnings in previous releases
A deprecation warning was added in the MariaDB Server 10.2.2, well before it was Generally Available. That said, maybe there is a nontrivial amount of users who skipped the 10.2 release and upgraded straight from 10.1 to 10.3.
come on and show me! [root@localhost:~]$ cat mysql_error.log 2019-09-02 17:11:43 139645497730816 [Note] /usr/libexec/mysqld (initiated by: unknown): Normal shutdown 2019-09-02 17:11:43 139645073479424 [Note] InnoDB: FTS optimize thread exiting. 2019-09-02 17:11:43 139645497730816 [Note] Event Scheduler: Purging the queue. 0 events 2019-09-02 17:11:43 139645498156800 [Note] Error reading relay log event: slave SQL thread was killed 2019-09-02 17:11:43 139645498156800 [Note] Slave SQL thread exiting, replication stopped in log 'bin.002679' at position 49489 2019-09-02 17:11:43 139645498464000 [Note] Slave I/O thread exiting, read up to log 'bin.002679', position 49489 2019-09-02 17:11:43 139645497730816 [Note] InnoDB: Starting shutdown... 2019-09-02 17:11:45 139645497730816 [Note] InnoDB: Shutdown completed; log sequence number 201835120033 2019-09-02 17:11:45 139645497730816 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" 2019-09-02 17:11:45 139645497730816 [Note] /usr/libexec/mysqld: Shutdown complete 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Uses event mutexes 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Compressed tables use zlib 1.2.11 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Using Linux native AIO 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Number of pools: 1 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Using SSE2 crc32 instructions 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Initializing buffer pool, total size = 64M, instances = 1, chunk size = 64M 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Completed initialization of buffer pool 2019-09-02 17:11:45 139893416630016 [Note] InnoDB: page_cleaner coordinator priority: -20 2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Highest supported file format is Barracuda. 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: 128 out of 128 rollback segments are active. 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Creating shared tablespace for temporary tables 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Waiting for purge to start 2019-09-02 17:11:46 139893743717888 [Note] InnoDB: 5.7.27 started; log sequence number 201835120033 2019-09-02 17:11:46 139893275596544 [Note] InnoDB: Loading buffer pool(s) from /Volumes/dune/mysql/mysql_dbmail/ib_buffer_pool 2019-09-02 17:11:46 139893275596544 [Note] InnoDB: Cannot open '/Volumes/dune/mysql/mysql_dbmail/ib_buffer_pool' for reading: No such file or directory 2019-09-02 17:11:46 139893743717888 [Note] Server socket created on IP: '0.0.0.0'. 2019-09-02 17:11:46 139893743717888 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.2.26-MariaDB' socket: '/var/lib/mysql/mysqld_dbmail.sock' port: 3307 thelounge 2019-09-02 17:11:46 139893708191488 [Note] Slave SQL thread initialized, starting replication in log 'bin.002679' at position 49489, relay log './mysql-relay-bin.983139' position: 549 2019-09-02 17:11:46 139893708498688 [Note] Slave I/O thread: connected to master 'replication@c*********:3307',replication started in log 'bin.002679' at position 49489 [root@localhost:~]$
Reindl Harald <h.reindl@thelounge.net>, 02/09/2019 – 18:12:53 (+0200):
Maybe giving us the version you are upgrading from would have been a better starting point.
maybe read what i wrote instead cut down my post by the first line would be a god start too or simply shut up when you are too lazy read a log starting with "Normal shutdown" and ending with "Version: '10.2.26-MariaDB'" leaded by "come on and show me!" would be a good start! I am truly sorry by the issue you are facing, but giving us *in your first post* the version and the OS would have been more productive IMHO.
* you come up with "since you skipped over directly to 10.3" Wrong person...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 02.09.19 um 19:38 schrieb Faustin Lammler:
I am truly sorry by the issue you are facing, but giving us *in your first post* the version and the OS would have been more productive IMHO
don't get me wrong *but* i find it insulting when someone accueses me that i jump from some random completly outdated version to 10.3.x and then come up with "but why where the no warning in 10.0/10.1 that something disappears in 10.3" that's what i call common sense on both sides anyways, the real problem i have with your response is that you jumped into two posts between me and a core developer and stripped everything relevant while i showed a complete restart log without any mentioning of "innodb_support_xa" at all and asked where the warning is the core developer talked about and yes, i assumed that a core developer other than you would look at that startup log, came to the conslusion "indeed, no warning there" and while read the few lines "indeed, the latest 10.2 version" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEnStGzbwUCjZ1OuTXMxdNWliSt7gFAl1tVYEACgkQMxdNWliS t7jqpgv+NcClSSpeisaLqPNv7uRm4OhbNYdteyUxXVDMP1DxBTH6i0D+D1/LRqcE aYcl68l3Ttw34+uCM1oIgY2hutOWb7h4uzzrC7ZxFDsCKU+5b+ZzbSN9jcL5GPWt z3ArTZS5jUzkPUGcQDqYrEoFqc8HOjYM6pOr0YeFZMFPmURM4LB0q+kumezn7E6i K0A1GKYebJ0EHsiIQs8r+J3ZZLMPD6K+6Fkk0dB07NIArfDa6VPOXGL2r4/X5sP4 yodVgHWhXGW5dkpyjUuyBoB1IloqqxsutGGiwbLkMS6x9OuUsCq5HaDFau0WDQGH Kt+CaeCBVwYpsozsgGgPoOnbmUgaoVxGG7pERnbSxrN2X2l5ACgGxpY8Q9nNOGsi 7DJFZm7vOf0M3sOR9XgZ4TWiPbtV2QSWuy9bNNXyiL7LZWAMjfmwsTQFLRGGMwkW tQZPr/OWbN1xd15dxKu7NHwjCLqxdIwE0n2e8itlU6syzivquepinTGQg7a5D09r L3dqqB5L =SGe9 -----END PGP SIGNATURE-----
On Mon, Sep 2, 2019 at 8:48 PM Reindl Harald <h.reindl@thelounge.net> wrote:
and yes, i assumed that a core developer other than you would look at that startup log, came to the conslusion "indeed, no warning there" and while read the few lines "indeed, the latest 10.2 version"
You are right that a warning should be issued for deprecated variables if any value was specified in the configuration file or by a command line option. Unfortunately, I am not aware how a storage engine could distinguish the compile-time default value from a user-specified identical value. That is why InnoDB did not issue the deprecation warning for you. Maybe you can submit a fix that would address this deficiency? Best regards, Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
Am 02.09.19 um 20:20 schrieb Marko Mäkelä:
On Mon, Sep 2, 2019 at 8:48 PM Reindl Harald <h.reindl@thelounge.net> wrote:
and yes, i assumed that a core developer other than you would look at that startup log, came to the conslusion "indeed, no warning there" and while read the few lines "indeed, the latest 10.2 version"
You are right that a warning should be issued for deprecated variables if any value was specified in the configuration file or by a command line option.
Unfortunately, I am not aware how a storage engine could distinguish the compile-time default value from a user-specified identical value. That is why InnoDB did not issue the deprecation warning for you. Maybe you can submit a fix that would address this deficiency?
sadly i am not a C/C++ delevoper but i would expect it to be as simple as two simple *global* lists $known_options = ['innodb_support_xa', 'performance-schema=0', ...] $deprecated_options ['innodb_support_xa', ....] -DPLUGIN_PARTITION=NO, -DPLUGIN_PERFSCHEMA=NO where broken in multiple point releases the past years and everytime one decided "well, then disable that build option and use the config option to disable it" leaded later in "oh fuck, now the the build was fixed it no longer starts because of the now unknown option" a simple lookup in "known_options" and react with a generic warning that this option is not supported in the current build instead refuse to start and refuse only when a total unknownm option appears would have safed a lot of headache
Hi, Marko! On Sep 02, Marko Mäkelä wrote:
On Mon, Sep 2, 2019 at 8:48 PM Reindl Harald <h.reindl@thelounge.net> wrote:
and yes, i assumed that a core developer other than you would look at that startup log, came to the conslusion "indeed, no warning there" and while read the few lines "indeed, the latest 10.2 version"
You are right that a warning should be issued for deprecated variables if any value was specified in the configuration file or by a command line option.
Unfortunately, I am not aware how a storage engine could distinguish the compile-time default value from a user-specified identical value. That is why InnoDB did not issue the deprecation warning for you.
I thought that we could've changed the default to, say, 2. Then both 1 and 0 would mean that the value was specificed explicitly. Or something like that. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
Am 02.09.19 um 19:38 schrieb Faustin Lammler:
I am truly sorry by the issue you are facing, but giving us *in your first post* the version and the OS would have been more productive IMHO
don't get me wrong *but* i find it insulting when someone accueses me that i jump from some random completly outdated version to 10.3.x and then come up with "but why where the no warning in 10.0/10.1 that something disappears in 10.3"
that's what i call common sense on both sides
anyways, the real problem i have with your response is that you jumped into two posts between me and a core developer and stripped everything relevant while i showed a complete restart log without any mentioning of "innodb_support_xa" at all and asked where the warning is the core developer talked about
No he did not, i did, and for that i am mildly sorry, and only mildly because of the tone you used since the beginning of the discussion but i should have keep my calm. As for your 'kind suggestion' of handling deprecated/unknown option i personnally strongly disagree, some of mysql/mariadb options have real impact and "physical" consequences on the database, preventing it to start because of setting not handled is way safer that ignoring them and only putting a warning in the logs. Apache doesn't start when you try to setup a plugin that is not loaded, nginx doesn't start when the configuration cannot be processed with the current build...
Am 03.09.19 um 09:50 schrieb Benoit Plessis:
Am 02.09.19 um 19:38 schrieb Faustin Lammler:
I am truly sorry by the issue you are facing, but giving us *in your first post* the version and the OS would have been more productive IMHO
don't get me wrong *but* i find it insulting when someone accueses me that i jump from some random completly outdated version to 10.3.x and then come up with "but why where the no warning in 10.0/10.1 that something disappears in 10.3"
that's what i call common sense on both sides
anyways, the real problem i have with your response is that you jumped into two posts between me and a core developer and stripped everything relevant while i showed a complete restart log without any mentioning of "innodb_support_xa" at all and asked where the warning is the core developer talked about
No he did not, i did, and for that i am mildly sorry, and only mildly because of the tone you used since the beginning of the discussion but i should have keep my calm.
yes
As for your 'kind suggestion' of handling deprecated/unknown option i personnally strongly disagree, some of mysql/mariadb options have real impact and "physical" consequences on the database, preventing it to start because of setting not handled is way safer that ignoring them and only putting a warning in the logs.
"-DPLUGIN_PERFSCHEMA=NO" is the same as "performance-schema=0" is doing the same while "performance-schema=0" on a binary with the built with the first one prevents mysqld from start when i *explicit disable* some bloatware crap it's missing exitence is not a hard error that is idiotic, the same for partitioning and so on any fucking option from the documentation must not trigger hard errors when it exists in a config file, no matter what - period
On 03/09/2019 11:25, Reindl Harald wrote:
yes
Yet you continue using an inappropriate tone/wording just below ... maybe you could take a bit of your own advice don't you think ?
"-DPLUGIN_PERFSCHEMA=NO" is the same as "performance-schema=0" is doing the same while "performance-schema=0" on a binary with the built with the first one prevents mysqld from start
Well the end-result might be the same, technically you did build another software with no support of this option.
when i *explicit disable* some bloatware crap it's missing exitence is not a hard error Well, so you want to add some "bloat" to a software to handle deprecated bloated "crap", are you sure to think it through ?
Am 03.09.19 um 11:38 schrieb Benoit Plessis:
On 03/09/2019 11:25, Reindl Harald wrote:
when i *explicit disable* some bloatware crap it's missing exitence is not a hard error Well, so you want to add some "bloat" to a software to handle deprecated bloated "crap", are you sure to think it through?
a simple array with all known config options is bloat? have you ever written software in any language? --------- and for the Apache and nginx: [root@srv-rhsoft:~]$ apachectl -t AH00526: Syntax error on line 14 of /etc/httpd/conf/httpd-prefork.conf: Invalid command 'ddd=dfdfdf', perhaps misspelled or defined by a module not included in the server configuration where is something similar for mariadb/mysqld *before* restart the service?
On 03/09/2019 11:45, Reindl Harald wrote:
a simple array with all known config options is bloat? have you ever written software in any language?
C/C++/perl/shell/java/Coldfusion pick whatever you want... But i spent more time doing admin and fighting leaks and instability
and for the Apache and nginx:
[root@srv-rhsoft:~]$ apachectl -t AH00526: Syntax error on line 14 of /etc/httpd/conf/httpd-prefork.conf: Invalid command 'ddd=dfdfdf', perhaps misspelled or defined by a module not included in the server configuration
where is something similar for mariadb/mysqld *before* restart the service?
Yes, that could be nice, not sure if it's really top priority...
Am 03.09.19 um 11:53 schrieb Benoit Plessis:
[root@srv-rhsoft:~]$ apachectl -t AH00526: Syntax error on line 14 of /etc/httpd/conf/httpd-prefork.conf: Invalid command 'ddd=dfdfdf', perhaps misspelled or defined by a module not included in the server configuration
where is something similar for mariadb/mysqld *before* restart the service?
Yes, that could be nice, not sure if it's really top priority...
for a service which simply refuses to restart because of some unkown option as result of a different build option it's *mandatory* not just nice, especially when build-options are known to randomly break between bugfix releases
and for the Apache and nginx:
[root@srv-rhsoft:~]$ apachectl -t AH00526: Syntax error on line 14 of /etc/httpd/conf/httpd-prefork.conf: Invalid command 'ddd=dfdfdf', perhaps misspelled or defined by a module not included in the server configuration
where is something similar for mariadb/mysqld *before* restart the service?
There kind of is as of mysql 8.x (and I assume 10.4.x maria, haven't migrated/tested yet so not sure) mysqld --validate-config https://dev.mysql.com/doc/refman/8.0/en/server-configuration-validation.html Could be a nice feature to backport to older trees .. rr
Hi, Benoit! On Sep 03, Benoit Plessis wrote:
As for your 'kind suggestion' of handling deprecated/unknown option i personnally strongly disagree, some of mysql/mariadb options have real impact and "physical" consequences on the database, preventing it to start because of setting not handled is way safer that ignoring them and only putting a warning in the logs.
Note, that his use case is an option that was explicitly set to its default value in my.cnf, and in 10.3 was removed in the server (so the default value became hard-coded behavior and not configurable anymore). That is, the option had no consequences, if it had, if it was set to a non-default value, he'd get a warning in 10.2. And removal of an option in 10.3 did not change InnoDB behavior for him, the only effect was that the option stopped being recognized by the server and the server refused to start. So in this specific case, recognizing an option in 10.3 with a warning could've been justified. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
On 03/09/2019 11:31, Sergei Golubchik wrote:
Hi, Benoit!
[..]
Note, that his use case is an option that was explicitly set to its default value in my.cnf, and in 10.3 was removed in the server (so the default value became hard-coded behavior and not configurable anymore).
That is, the option had no consequences, if it had, if it was set to a non-default value, he'd get a warning in 10.2.
And removal of an option in 10.3 did not change InnoDB behavior for him, the only effect was that the option stopped being recognized by the server and the server refused to start.
So in this specific case, recognizing an option in 10.3 with a warning could've been justified.
Hi Sergei, Yes i got this, but still, i largely prefer mysql/maria to not start so i know something is wrong, to bloating to code for handling potentially not built / removed options. In this case maybe to deprecated should have been handled better yes but hey, that doesn't justify this tone. I have lost many more hour with lost sleep and data corruption with maria recently but i did not insult anyone ... Nor when i hit my head trying to counter some performance degradation since the jump to maria in some inefficient query parsing. In any case that's your software so
Hi Faustin, On Mon, Sep 2, 2019 at 7:05 PM Faustin Lammler <faustin@fala.red> wrote: [snip]
Anyway, there maybe some useful information here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920608
Marko, I believe we can expect these kinds of deprecation with people upgrading from Debian Stretch to Buster.
Yes, it is possible. That Debian bug was special in that the options used to be part of the Debian-shipped configuration file. The user who reported the bug had edited the configuration file that was shipped with the older version, so the Debian upgrade would notice a conflict and ask the user what to do. Apparently the user chose to preserve the original configuration (with the modifications), and as a result, MariaDB Server 10.3 would fail to start up. I addressed this by adding back these as string parameters, and issuing a deprecation warning whenever any value is specified. Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
Hi, Reindl! On Sep 02, Reindl Harald wrote:
Am 02.09.19 um 17:09 schrieb Marko Mäkelä:
On Mon, Sep 2, 2019 at 5:43 PM Reindl Harald <h.reindl@thelounge.net> wrote:
unknown variable 'innodb_support_xa=1'
would you funny guys consider things like deperectaion warnings in previous releases
A deprecation warning was added in the MariaDB Server 10.2.2, well before it was Generally Available. That said, maybe there is a nontrivial amount of users who skipped the 10.2 release and upgraded straight from 10.1 to 10.3.
come on and show me!
Here, warnings as added in 10.2.2: https://github.com/MariaDB/server/blob/mariadb-10.2.2/storage/innobase/handl... But you're still right, you did not see them. The warning (if I read the sources correctly), was issued when innodb_support_xa was changed run-time or when MariaDB was started with innodb_support_xa=0. For the initial innodb_support_xa=1 there was no warning (because 1 was the default value for innodb_support_xa). Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
Am 02.09.19 um 19:21 schrieb Sergei Golubchik:
On Sep 02, Reindl Harald wrote:
Am 02.09.19 um 17:09 schrieb Marko Mäkelä:
On Mon, Sep 2, 2019 at 5:43 PM Reindl Harald <h.reindl@thelounge.net> wrote:
unknown variable 'innodb_support_xa=1'
would you funny guys consider things like deperectaion warnings in previous releases
A deprecation warning was added in the MariaDB Server 10.2.2, well before it was Generally Available. That said, maybe there is a nontrivial amount of users who skipped the 10.2 release and upgraded straight from 10.1 to 10.3.
come on and show me!
Here, warnings as added in 10.2.2:
https://github.com/MariaDB/server/blob/mariadb-10.2.2/storage/innobase/handl...
But you're still right, you did not see them.
The warning (if I read the sources correctly), was issued when innodb_support_xa was changed run-time or when MariaDB was started with innodb_support_xa=0. For the initial innodb_support_xa=1 there was no warning (because 1 was the default value for innodb_support_xa)
smart admins prefer fixed configurations in case some sloppy commit or minor update changes the default well, and that's a problem given that you refuse to start the server just because you don't understand a random config option and so no matter how much tests one is running the matrix of available and potentially silent disappearing options means "good luck when you update" not only when you update, also when because of a changed or broken cmake optionsthe binary of the old version supported something which the new don't and the attitude of MariaDB adding new features to existing GA releases or randomly break compile options between minor versions make that a very uncomfortable world to live for admins just don't refuse to start the service becaus eof such things it's as simple as compile a list of all known and previous known options and isssue only a warning instead of a fatal error if they are not supported with the current build no matter why innodb_support_xa=1 == deperaction warning innodb_support_xb=1 == you recently added soemthing with a typo
participants (6)
-
Benoit Plessis -
Faustin Lammler -
Marko Mäkelä -
Reindl Harald -
Reinis Rozitis -
Sergei Golubchik