Re: [Maria-developers] MariaDB Debian deprecation policy
I think the dates listed at https://wiki.debian.org/LTS should be used as guidelines. Squeeze LTS will be supported until Feb 2016. On 06/05/2015 21:08, Otto Kekäläinen wrote: Hello! 2015-05-06 21:42 GMT+03:00 Daniel Bartholomew db...@mariadb.com: On the MariaDB Deprecation Policy page we list planned deprecation dates for most of the platforms we build on. https://mariadb.com/kb/en/mariadb/deprecation-policy/ The various Debian releases we build for are listed, but there are no deprecation dates. According to https://www.debian.org/releases/ with the release of Debian 8 Jessie both Squeeze and Wheezy are now obsolete. Should we deprecate both of them and stop providing builds? Or should we just deprecate Squeeze? There are people maintaining so called LTS updates for both Squeeze and Wheezy. It all depends on what we want to promise to the users. Maybe the sensible policy would be to support the two latest Debian releases? Or just the latest Debian release + 6 months of transition between versions? Anyway I think that at least squeeze builds are ok to drop and move all those resources into Jessie builds and QA. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 845edb6: MDEV-7067: Server outputs Galera (WSREP) information, even if Galera is disabled
Hi, Nirbhay!
On Apr 08, Nirbhay Choubey wrote:
revision-id: 845edb6259559bed39eb7365860aa5d588990775
parent(s): 3674c363a7e77e534c3e0d28659dc614c53fbcbc
committer: Nirbhay Choubey
branch nick: 10.1-wsrep
timestamp: 2015-04-08 16:49:57 -0400
message:
MDEV-7067: Server outputs Galera (WSREP) information, even if Galera is
disabled
- mysqld_safe: Skip wsrep position recovery if wsrep_on variable
(mandatory since 10.1) is not specified
ok
- Do not load dummy wsrep provider if wsrep_on is not ON
see below
- Remove -wsrep from server version
ok
I'd also move wsrep_25.10.r4144 from version_comment to a separate
variable, like, wsrep_version.
diff --git a/sql/wsrep_var.cc b/sql/wsrep_var.cc
index ca921b7..1cd0a54 100644
--- a/sql/wsrep_var.cc
+++ b/sql/wsrep_var.cc
@@ -295,6 +295,8 @@ bool wsrep_provider_options_check(sys_var *self, THD*
thd, set_var* var)
bool wsrep_provider_options_update(sys_var *self, THD* thd, enum_var_type
type)
{
+ if (!wsrep) return false;
+
What about that comment by Alexey Yurchenko?
The one where he says that checking for wsrep being not NULL inside
wsrep functions is never needed, because wsrep functions should be never
even called if wsrep is not enabled.
Regards,
Sergei
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
[Maria-developers] Windows line endings in source files (Re: [Maria-discuss] MariaDB 10.0.18 now available)
While preparing the Debian updates I noticed git complaning: The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in storage/spider/mysql-test/spider/t/have_partition.inc. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in storage/spider/mysql-test/spider/t/have_trigger.inc. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in storage/spider/mysql-test/spider/t/spider3_fixes.test. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in storage/spider/mysql-test/spider/t/spider3_fixes_part.test. Turns out a lot of source files in this release has Windows line endings: mariadb-10.0/mysql-test/r/func_regexp_pcre.result mariadb-10.0/mysql-test/r/loadxml.result mariadb-10.0/mysql-test/r/mysql_binary_mode.result mariadb-10.0/mysql-test/r/perror-win.result mariadb-10.0/mysql-test/std_data/loaddata7.dat mariadb-10.0/mysql-test/std_data/loadxml2.dat mariadb-10.0/packaging/WiX/CPackWixConfig.cmake mariadb-10.0/packaging/WiX/create_msi.cmake.in mariadb-10.0/packaging/WiX/custom_ui.wxs mariadb-10.0/packaging/WiX/extra.wxs.in mariadb-10.0/packaging/WiX/mysql_server.wxs.in mariadb-10.0/pcre/RunTest.bat mariadb-10.0/pcre/testdata/greppatN4 mariadb-10.0/sql/message.rc mariadb-10.0/sql/winservice.h mariadb-10.0/storage/connect/colblk.cpp mariadb-10.0/storage/connect/mysql-test/connect/my.cnf mariadb-10.0/storage/connect/mysql-test/connect/std_data/biblio.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/bookstore.xml mariadb-10.0/storage/connect/mysql-test/connect/std_data/boyswin.txt mariadb-10.0/storage/connect/mysql-test/connect/std_data/emp.txt mariadb-10.0/storage/connect/mysql-test/connect/std_data/expense.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/expenses.txt mariadb-10.0/storage/connect/mysql-test/connect/std_data/mulexp3.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/mulexp4.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/mulexp5.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/sexe.csv mariadb-10.0/storage/connect/mysql-test/connect/std_data/sitmat.csv mariadb-10.0/storage/connect/mysql-test/connect/t/alter.test mariadb-10.0/storage/connect/mysql-test/connect/t/alter_xml.test mariadb-10.0/storage/connect/mysql-test/connect/t/bin.test mariadb-10.0/storage/connect/mysql-test/connect/t/datest.test mariadb-10.0/storage/connect/mysql-test/connect/t/fmt.test mariadb-10.0/storage/connect/mysql-test/connect/t/general.test mariadb-10.0/storage/connect/mysql-test/connect/t/json.test mariadb-10.0/storage/connect/mysql-test/connect/t/json_udf.test mariadb-10.0/storage/connect/mysql-test/connect/t/mrr.test mariadb-10.0/storage/connect/mysql-test/connect/t/mul.test mariadb-10.0/storage/connect/mysql-test/connect/t/myconn.inc mariadb-10.0/storage/connect/mysql-test/connect/t/myconn_cleanup.inc mariadb-10.0/storage/connect/mysql-test/connect/t/mysql.test mariadb-10.0/storage/connect/mysql-test/connect/t/mysql_discovery.test mariadb-10.0/storage/connect/mysql-test/connect/t/mysql_exec.test mariadb-10.0/storage/connect/mysql-test/connect/t/mysql_grant.test mariadb-10.0/storage/connect/mysql-test/connect/t/mysql_new.test mariadb-10.0/storage/connect/mysql-test/connect/t/null.test mariadb-10.0/storage/connect/mysql-test/connect/t/occur.test mariadb-10.0/storage/connect/mysql-test/connect/t/odbc_sqlite3.test mariadb-10.0/storage/connect/mysql-test/connect/t/part_file.test mariadb-10.0/storage/connect/mysql-test/connect/t/part_table.test mariadb-10.0/storage/connect/mysql-test/connect/t/pivot.test mariadb-10.0/storage/connect/mysql-test/connect/t/tbl.test mariadb-10.0/storage/connect/mysql-test/connect/t/unsigned.test mariadb-10.0/storage/connect/mysql-test/connect/t/upd.test mariadb-10.0/storage/connect/mysql-test/connect/t/updelx.test mariadb-10.0/storage/connect/mysql-test/connect/t/updelx2.test mariadb-10.0/storage/connect/mysql-test/connect/t/xcol.test mariadb-10.0/storage/connect/mysql-test/connect/t/xml_mdev5261.test mariadb-10.0/storage/connect/rcmsg.c mariadb-10.0/storage/connect/tabsys.h mariadb-10.0/storage/federatedx/README.windows mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_deinit_child3_1.inc mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_deinit_child3_2.inc mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_deinit_child3_3.inc mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_init_child2_1.inc mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_init_child2_2.inc mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_init_child2_3.inc mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_init_child3_1.inc mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_init_child3_2.inc
Re: [Maria-developers] [Commits] 93e746a: MDEV-7793 - Race condition between XA COMMIT/ROLLBACK and disconnect
Hi Sergei,
On Thu, May 07, 2015 at 01:04:24PM +0200, Sergei Golubchik wrote:
Hi, Sergey!
On Mar 17, s...@mariadb.org wrote:
revision-id: 93e746afb2d1a23cb933291ad736a20858b5ac3e
parent(s): ccc7297fe94af1129c717f91d31fa075d54a0371
committer: Sergey Vojtovich
branch nick: mariadb
timestamp: 2015-03-17 19:49:04 +0400
message:
MDEV-7793 - Race condition between XA COMMIT/ROLLBACK and disconnect
XA COMMIT/ROLLBACK of XA transaction owned by different thread may access
freed memory if that thread disconnects at the same time.
Also concurrent XA COMMIT/ROLLBACK of recovered XA transaction were not
serialized properly.
diff --git a/sql/sql_class.cc b/sql/sql_class.cc
index 3071ba6..f18231d 100644
--- a/sql/sql_class.cc
+++ b/sql/sql_class.cc
@@ -5355,7 +5378,7 @@ bool xid_cache_insert(THD *thd, XID_STATE *xid_state)
switch (res)
{
case 0:
-xid_state-xid_cache_element-mark_initialized();
+xid_state-xid_cache_element-set(XID_cache_element::ACQUIRED);
Why not mark_acquired() here?
mark_acquired() is intended to acquire RECOVERED elements. That is to allow
multiple threads to attempt to acquire the same XID. One thread will succeed,
others will get not found.
Can you be sure that no other thread has already acquired this
xid_cache_element after you've inserted it?
Only RECOVERED elements can be acquired. This newly inserted element has
m_state == 0.
Thanks,
Sergey
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 93e746a: MDEV-7793 - Race condition between XA COMMIT/ROLLBACK and disconnect
Hi, Sergey! On May 07, Sergey Vojtovich wrote: On Thu, May 07, 2015 at 01:04:24PM +0200, Sergei Golubchik wrote: Hi, Sergey! On Mar 17, s...@mariadb.org wrote: revision-id: 93e746afb2d1a23cb933291ad736a20858b5ac3e parent(s): ccc7297fe94af1129c717f91d31fa075d54a0371 committer: Sergey Vojtovich branch nick: mariadb timestamp: 2015-03-17 19:49:04 +0400 message: MDEV-7793 - Race condition between XA COMMIT/ROLLBACK and disconnect XA COMMIT/ROLLBACK of XA transaction owned by different thread may access freed memory if that thread disconnects at the same time. Also concurrent XA COMMIT/ROLLBACK of recovered XA transaction were not serialized properly. Why not mark_acquired() here? mark_acquired() is intended to acquire RECOVERED elements. Ok to push, but please mention this in the method comment. Regards, Sergei ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Proposal accepted for GSoc'15
Yeah, sure. I will do that today. On Thu, May 07, 2015 at 10:55 PM, Markus Mäkelä markus.mak...@mariadb.com [markus.mak...@mariadb.com] wrote: Hi, Glad to have you working on MaxScale and I'm excited as well! If you want to, you can also introduce yourself on the MaxScale Google Group. (maxsc...@googlegroups.com) Markus On Thu, 2015-05-07 at 20:26 +0530, sriram patil wrote: Hi All, I am Sriram from IIIT Hyderabad, India. I am a Masters' student here. I have worked with MariaDB in GSoC'14 with Alexander Barkov. I had great time hacking on MariaDB last year, so, here I am again. :) This year I will be working on MaxScale filters with Markus Makela. The project title is MaxScale filter to capture incoming operations for consumption in external sources. (MXS-2) I am excited to get started. Hoping to have a great summer this year as well. :) Thanks, Sriram Patil -- Markus Mäkelä, Software Engineer MariaDB Corporation t: +358 40 7740484 | Skype: markus.j.makela___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Windows line endings in source files (Re: [Maria-discuss] MariaDB 10.0.18 now available)
I'm not sure why you saw this the first time in two years, I was seeing this since pretty much the beginning of 10.0: https://mariadb.atlassian.net/browse/MDEV-4447. And even though the bug is marked Fixed, Windows line endings have never disappeared from MariaDB tarballs. On Thu, May 7, 2015 at 2:16 PM, Otto Kekäläinen o...@seravo.fi wrote: While preparing the Debian updates I noticed git complaning: The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in storage/spider/mysql-test/spider/t/have_partition.inc. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in storage/spider/mysql-test/spider/t/have_trigger.inc. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in storage/spider/mysql-test/spider/t/spider3_fixes.test. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in storage/spider/mysql-test/spider/t/spider3_fixes_part.test. Turns out a lot of source files in this release has Windows line endings: mariadb-10.0/mysql-test/r/func_regexp_pcre.result mariadb-10.0/mysql-test/r/loadxml.result mariadb-10.0/mysql-test/r/mysql_binary_mode.result mariadb-10.0/mysql-test/r/perror-win.result mariadb-10.0/mysql-test/std_data/loaddata7.dat mariadb-10.0/mysql-test/std_data/loadxml2.dat mariadb-10.0/packaging/WiX/CPackWixConfig.cmake mariadb-10.0/packaging/WiX/create_msi.cmake.in mariadb-10.0/packaging/WiX/custom_ui.wxs mariadb-10.0/packaging/WiX/extra.wxs.in mariadb-10.0/packaging/WiX/mysql_server.wxs.in mariadb-10.0/pcre/RunTest.bat mariadb-10.0/pcre/testdata/greppatN4 mariadb-10.0/sql/message.rc mariadb-10.0/sql/winservice.h mariadb-10.0/storage/connect/colblk.cpp mariadb-10.0/storage/connect/mysql-test/connect/my.cnf mariadb-10.0/storage/connect/mysql-test/connect/std_data/biblio.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/bookstore.xml mariadb-10.0/storage/connect/mysql-test/connect/std_data/boyswin.txt mariadb-10.0/storage/connect/mysql-test/connect/std_data/emp.txt mariadb-10.0/storage/connect/mysql-test/connect/std_data/expense.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/expenses.txt mariadb-10.0/storage/connect/mysql-test/connect/std_data/mulexp3.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/mulexp4.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/mulexp5.json mariadb-10.0/storage/connect/mysql-test/connect/std_data/sexe.csv mariadb-10.0/storage/connect/mysql-test/connect/std_data/sitmat.csv mariadb-10.0/storage/connect/mysql-test/connect/t/alter.test mariadb-10.0/storage/connect/mysql-test/connect/t/alter_xml.test mariadb-10.0/storage/connect/mysql-test/connect/t/bin.test mariadb-10.0/storage/connect/mysql-test/connect/t/datest.test mariadb-10.0/storage/connect/mysql-test/connect/t/fmt.test mariadb-10.0/storage/connect/mysql-test/connect/t/general.test mariadb-10.0/storage/connect/mysql-test/connect/t/json.test mariadb-10.0/storage/connect/mysql-test/connect/t/json_udf.test mariadb-10.0/storage/connect/mysql-test/connect/t/mrr.test mariadb-10.0/storage/connect/mysql-test/connect/t/mul.test mariadb-10.0/storage/connect/mysql-test/connect/t/myconn.inc mariadb-10.0/storage/connect/mysql-test/connect/t/myconn_cleanup.inc mariadb-10.0/storage/connect/mysql-test/connect/t/mysql.test mariadb-10.0/storage/connect/mysql-test/connect/t/mysql_discovery.test mariadb-10.0/storage/connect/mysql-test/connect/t/mysql_exec.test mariadb-10.0/storage/connect/mysql-test/connect/t/mysql_grant.test mariadb-10.0/storage/connect/mysql-test/connect/t/mysql_new.test mariadb-10.0/storage/connect/mysql-test/connect/t/null.test mariadb-10.0/storage/connect/mysql-test/connect/t/occur.test mariadb-10.0/storage/connect/mysql-test/connect/t/odbc_sqlite3.test mariadb-10.0/storage/connect/mysql-test/connect/t/part_file.test mariadb-10.0/storage/connect/mysql-test/connect/t/part_table.test mariadb-10.0/storage/connect/mysql-test/connect/t/pivot.test mariadb-10.0/storage/connect/mysql-test/connect/t/tbl.test mariadb-10.0/storage/connect/mysql-test/connect/t/unsigned.test mariadb-10.0/storage/connect/mysql-test/connect/t/upd.test mariadb-10.0/storage/connect/mysql-test/connect/t/updelx.test mariadb-10.0/storage/connect/mysql-test/connect/t/updelx2.test mariadb-10.0/storage/connect/mysql-test/connect/t/xcol.test mariadb-10.0/storage/connect/mysql-test/connect/t/xml_mdev5261.test mariadb-10.0/storage/connect/rcmsg.c mariadb-10.0/storage/connect/tabsys.h mariadb-10.0/storage/federatedx/README.windows mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_deinit_child3_1.inc mariadb-10.0/storage/spider/mysql-test/spider/bg/include/ha_deinit_child3_2.inc
Re: [Maria-developers] Please review: MDEV-7824 [Bug #68041] Zero date can be inserted in strict no-zero mode through a default value
Hi, Alexander!
On Mar 25, Alexander Barkov wrote:
Hi Sergei,
Please review a patch for mdev-7824.
It's based on a MySQL patch for
http://bugs.mysql.com/bug.php?id=68041
and is a blocker for:
MDEV-3929 Add full support for auto-initialized/updated timestamp and
datetime
That looks good.
But I don't like it that you verify defaults for every row.
It's not very cheap. And neither defaults nor sql_mode can change in the
duration of one statement. It should be enough to test only once.
I'm not sure, though, how to do that with a minimal overhead. A couple
of bool's in TABLE, like
bool all_default_are_checked;
bool write_set_defaults_are_checked;
that are set to false at the beginning on INSERT,INSERT...SELECT,LOAD.
And used like that
bool TABLE::restore_record_and_validate_unset_fields(THD *thd, bool all)
{
restore_record(this, s-default_values);
if (all ? all_default_are_checked : write_set_defaults_are_checked)
return false;
if (all) all_default_are_checked= true;
else write_set_defaults_are_checked= true;
return validate_default_values_of_unset_fields(thd);
}
and in mysql_insert():
if (fields.elements || !value_count)
{
if (table-restore_record_and_validate_unset_fields(thd, !value_count))
Regards,
Sergei
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
[Maria-developers] Proposal accepted for GSoc'15
Hi All, I am Sriram from IIIT Hyderabad, India. I am a Masters' student here. I have worked with MariaDB in GSoC'14 with Alexander Barkov. I had great time hacking on MariaDB last year, so, here I am again. :) This year I will be working on MaxScale filters with Markus Makela. The project title is MaxScale filter to capture incoming operations for consumption in external sources. (MXS-2) I am excited to get started. Hoping to have a great summer this year as well. :) Thanks, Sriram Patil ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 313a970: MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover
Hi, Sergey! On Apr 08, s...@mariadb.org wrote: revision-id: 313a970cbe9ac523b0584d293e40bff66d4fbafc parent(s): 7d9e94e2e6c32b906d1d8469e58bc04b8da1c121 committer: Sergey Vojtovich branch nick: mariadb timestamp: 2015-04-08 10:55:51 +0400 message: MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover table Performance schema discovery fails if connection has no active database set. This happened due to restriction in SQL parser: table name with no database name is ambiguous in such case. Fixed by temporary substitution of default database with being discovered table database. ok to push Regards, Sergei ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
