Re: [Maria-developers] Galera-10.0 still does not work with rollbacks

[seppo . jaakola]

Quoting Jan Lindström :


Seppo,

Hi,

What means:

30925 15:10:36 [ERROR] Slave SQL: Could not execute Update_rows  
event on table test.table10_key_pk_parts_2_int_autoinc; Can't find  
record in 'table10_key_pk_parts_2_int_autoinc', Error_code: 1032;  
handler error HA_ERR_KEY_NOT_FOUND; the event's master log FIRST,  
end_log_pos 275, Internal MariaDB error code: 1032
130925 15:10:36 [Warning] WSREP: RBR event 4 Update_rows apply  
warning: 120, 136
130925 15:10:36 [ERROR] WSREP: Failed to apply trx: source:  
dd56a506-25da-11e3-b555-0fdde9a0e702 version: 2 local: 0 state:  
APPLYING flags: 1 conn_id: 12 trx_id: 2503 seqnos (l: 140, g: 136,  
s: 135, d: 50, ts: 1380111033191170111)
130925 15:10:36 [ERROR] WSREP: Failed to apply app buffer: seqno:  
136, status: WSREP_FATAL

 at galera/src/replicator_smm.cpp:apply_wscoll():52
 at galera/src/replicator_smm.cpp:apply_trx_ws():118
130925 15:10:36 [ERROR] WSREP: Node consistency compromized, aborting...

R:



This is a message of detected data inconsistency. Replicated update  
could not be processed because the row to be updated could not be  
found in this node's database. You will find file GRA_12_136.log in  
your data directory, and this file contains all binlog events for the  
offending transaction.


Node did emergency shutdown due to the inconsistency.

-seppo
--
http://www.codership.com  seppo.jaak...@codership.com
tel: +358 40 510 5938 skype: seppo_jaakola



___
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] MySQL bug affects mariaDB

[Peter Laursen]

I think the 'mysql' client with MariaDB has a similar problem as it has
with MySQL - refer?
http://bugs.mysql.com/bug.php?id=70443

MariaDB installer installs my.ini to /datadir - what with MariaDB is a
subfolder to /basedir.

The server will look for it correctly as the registry key defining the
service has a --default-file specification.  But the command line clients
don't read the registry key.


@Wlad?


-- Peter
-- Webyog
___
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] Galera-10.0 still does not work with rollbacks

[seppo . jaakola]

Quoting Kristian Nielsen :


Jan Lindström  writes:


The point I do not understant is at ha_savepoint

we have again:

if ((err= ht->savepoint_set(ht, thd, (uchar *)(sv+1)+ht->savepoint_offset)))

(gdb) p *sv
$3 = {prev = 0xa5a5a5a5a5a5a5a5, name = 0x7f505c007390 "A", length  
= 1, ha_list

= 0xa5a5a5a5a5a5a5a5, mdl_savepoint = {m_stmt_ticket = 0xa5a5a5a5a5a5a5a5,
m_trans_ticket = 0xa5a5a5a5a5a5a5a5}}
(gdb) p *(sv+1)
$2 = {prev = 0xa5a5a5a5a5a5a5a5, name = 0xa5a5a5a5a5a5a5a5 , length = 2779096485, ha_list =
0xa5a5a5a5a5a5a5a5, mdl_savepoint = {m_stmt_ticket = 0xa5a5a5a5a5a5a5a5,
m_trans_ticket = 0xa5a5a5a5a5a5a5a5}}

Again access to unitialized memory, sv is ok but sv+1 not


Note that it is not "sv+1". It is ((uchar *)sv+1) + ht->savepoint_offset.

I suppose that sv points to a memory block containing first a SAVEPOINT
object, and after that some extra bytes allocated per storage engine.

Then when SAVEPOINT is executed, we call into each storage engine
ht->savepoint_set() to ask it to execute the savepoint and store
engine-specific data in the allocated extra bytes at
(uchar *)(sv+1)+ht->savepoint_offset.

And later when ROLLBACK TO SAVEPOINT is executed, we ask the engine  
to execute

the (partial) rollback using whatever values it put into
(uchar *)(sv+1)+ht->savepoint_offset itself before.

So it is normal that the data is unitialised in ha_savepoint() - because this
is where we are calling into each engine to initialise it.

But the bug is that the WSREP patch disables this initialisation. So  
that when
we get to ha_rollback_to_savepoint(), the binlog code gets  
uninitialised data.


If you are wondering about the 0xa5a5a5a5a5a5a5a5 in *sv, isn't the most
likely that those fields are just not used anywhere in the code?

Disclaimer: This is the first time I'm looking at this code, but it seems
clear enough ...

 - Kristian.



Jan, why don't you file a bug report about this? Following these  
emails is getting tedious...


Did I understand it right that the problem is with "ROLLBACK TO  
SAVEPOINT...", where the designated savepoint does not exist? Did you  
try same test with MGC 5.5?


-seppo



--
http://www.codership.com  seppo.jaak...@codership.com
tel: +358 40 510 5938 skype: seppo_jaakola



___
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] Galera-10.0 still does not work with rollbacks

[Kristian Nielsen]

seppo.jaak...@codership.com writes:

> Did I understand it right that the problem is with "ROLLBACK TO
> SAVEPOINT...", where the designated savepoint does not exist? Did you

No. It is a very simple issue.

The beginning of binlog_savepoint_set() reads:

#ifdef WITH_WSREP
  if (wsrep_emulate_bin_log) DBUG_RETURN(0);
#endif /* WITH_WSREP */

So binlog_savepoint_set() does nothing in the Galera case.

But binlog_savepoint_rollback() reads:

#ifdef WITH_WSREP
  if (!wsrep_emulate_bin_log ...
#endif
  {
...
  }

  binlog_trans_log_truncate(thd, *(my_off_t*)sv);

Note that the binlog_trans_log_truncate() call is outside the if, so it _is_
executed even in the Galera case.

So the WSREP patch tries to disable some binlog savepoint code but does it
incorrectly. It disables setting the savepoint but not rolling it back, so the
latter gets invalid data. It needs to match up, so that _set() and _rollback()
match each other in what they do.

This issue is in the maria-10.0-galera tree. I did not check other Galera
trees (not sure which trees to check).

 - Kristian.

___
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] [GSoC] Request for code review

[QIU Shuang]

Hi Sergei,

This is Shuang, a participant for GSoC 2013 Kerberize MariaDB project. I want 
to ask the community to review the code before requesting for pull and send the 
MCA.
How could I send the codes? In a diff file? or from other approaches?

Thank you very much and best regards!
Sincerely, Shuang


___
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] [GSoC] Request for code review

[Sergei Golubchik]

Hi, QIU!

On Sep 27, QIU Shuang wrote:
> This is Shuang, a participant for GSoC 2013 Kerberize MariaDB project.
> I want to ask the community to review the code before requesting for
> pull and send the MCA.
> How could I send the codes? In a diff file? or from other approaches?

Do you have a tree on launchpad with your code?
Then the easiest way would be to propose a merge of your tree into
mariadb. See https://help.launchpad.net/Code/Review

Besides you should submit the MCA or put your code under a New BSD
License before the review, not after.

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] Questions re MDEV-4736 and MDEV-4739 (was Re: Spider's installation sql file)

[Sergey Vojtovich]

Hi Kentoku,

On Wed, Sep 25, 2013 at 02:53:17AM +0900, kentoku wrote:
> Hi Sergey,
> 
> > The above should have been fixed back in the beginning of 2012. Which
> MariaDB
> revision are you testing with?
> It's same as lp:~kentokushiba/maria/10.0.4-spider-3.0.
That's very strange. How did you build it and what command line options did
you use (including those that are listed in my.cnf)?

> By the way, I found a problem point in Spider. Currently it is fixed and
> pushed. And I can't reproduce assertion failure. Can you reproduce this
> failure yet?
I just tested 10.0.4-spider-3.0 with rev.3827, it still fails.

Regards,
Sergey

> 
> Thanks,
> Kentoku
> 
> 
> 
> 
> 2013/9/24 Sergey Vojtovich 
> 
> > Hi Kentoku,
> >
> > On Thu, Sep 19, 2013 at 11:47:33PM +0900, kentoku wrote:
> > > Hi Sergey,
> > >
> > > > I'm afraid fixing rnd_end() callers in the server may stall for a long
> > > time.
> > > O.K. No need to fix it if it is not easy. This request is not high
> > priority
> > > request.
> > >
> > > > Is it accaptable for spider to use bulk updates and deletes API instead
> > > > (see handler.h: start_bulk_update/start_bulk_delete).
> > > Spider use it already. This API is not used if target table has after
> > > trigger. I understand why this API is not used in this case, but it
> > > sometimes causes performance problem. So, I thought it is better to
> > prepare
> > > other choice for something wrong. Anyway, I will disable bulk
> > > updating/deleting feature without using API.
> > I see. Hope it is acceptable.
> >
> > >
> > > > Nope, it looks like a bug in thread pool. MDEV-4739 has different
> > trace,
> > > how
> > > did you get this one? Just executed given test?
> > > I got this trace when I try to reproduce MDEV-4739. I did as the
> > followings.
> > >
> > > 1. start mysqld
> > > 2. log in mysqld
> > > 3. mysql> CREATE TABLE t1 (a INT) ENGINE=InnoDB;
> > > 4. mysql> XA START 'xa1';
> > > 5. mysql> INSERT INTO t1 (a) VALUES (1),(2);
> > > 6. mysql> XA END 'xa1';
> > > 7. mysql> XA PREPARE 'xa1';
> > > 8. kill -9 mysqld_safe and mysqld from another terminal
> > > 9. start mysqld on gdb
> > >
> > > At that time, InnoDB and Spider were enabled and log-bin was disabled. So
> > > probably "total_ha_2pc > 1" was true, "opt_bin_log" was false.
> > > Does it help you?
> > We couldn't reproduce it yet. :(
> >
> > Looking through the code I noticed that call to thd_wait_begin() looks as
> > following:
> >
> > static void scheduler_wait_sync_begin(void) {
> >   thd_wait_begin(NULL, THD_WAIT_SYNC);
> > }
> >
> > Note that thd is always NULL. And it must be NULL at this point, because
> > we're
> > booting. But according to your trace thd is not NULL.
> >
> > #0  0x005eabf6 in thd_wait_begin (
> > thd=0x29da060, wait_type=10)
> > at /ssd1/mariadb-10.0.4/sql/sql_class.cc:4277
> > #1  0x0072a114 in scheduler_wait_sync_begin ()
> > at /ssd1/mariadb-10.0.4/sql/scheduler.cc:59
> > ...
> >
> > The above should have been fixed back in the beginning of 2012. Which
> > MariaDB
> > revision are you testing with?
> >
> > Thanks,
> > Sergey
> >
> >
> >
> > >
> > > Thanks,
> > > Kentoku
> > >
> > >
> > >
> > > 2013/9/19 Sergey Vojtovich 
> > >
> > > > Hi Kentoku,
> > > >
> > > > I'm adding MariaDB developers to CC.
> > > >
> > > > On Thu, Sep 19, 2013 at 01:19:13AM +0900, kentoku wrote:
> > > > > Hi Sergey,
> > > > >
> > > > > > But what kind of errors are possible in your case? Other storage
> > > > engines
> > > > > doesn't
> > > > > seem to suffer from this API violation.
> > > > >
> > > > > Spider support bulk updating and deleting for avoiding network
> > roundtrip
> > > > > between data node. Some times, last bulk updating is executed in
> > > > rnd_end()
> > > > > function. So rnd_end() has possibility getting errors from data node.
> > > > I'm afraid fixing rnd_end() callers in the server may stall for a long
> > > > time.
> > > > Is it accaptable for spider to use bulk updates and deletes API instead
> > > > (see handler.h: start_bulk_update/start_bulk_delete).
> > > >
> > > > > By the way, about MDEV-4739. I get the following stack trace.
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x005eabf6 in thd_wait_begin (thd=0x29da060,
> > > > > wait_type=10)
> > > > > at /ssd1/mariadb-10.0.4/sql/sql_class.cc:4277
> > > > > 4277  MYSQL_CALLBACK(thd->scheduler, thd_wait_begin, (thd,
> > > > wait_type));
> > > > > (gdb) print thd
> > > > > $1 = (THD *) 0x29da060
> > > > > (gdb) bt
> > > > > #0  0x005eabf6 in thd_wait_begin (
> > > > > thd=0x29da060, wait_type=10)
> > > > > at /ssd1/mariadb-10.0.4/sql/sql_class.cc:4277
> > > > > #1  0x0072a114 in scheduler_wait_sync_begin ()
> > > > > at /ssd1/mariadb-10.0.4/sql/scheduler.cc:59
> > > > > #2  0x00d6dc20 in my_sync (fd=23, my_flags=0)
> > > > > at /ssd1/mariadb-10.0.4/mysys/my_sync.c:76
> > > > > #3  0x00d6b54f in my_msync (fd=23,
> > > > > addr=0x77ff

Re: [Maria-developers] Galera-10.0 still does not work with rollbacks

[Jan Lindström]

  
  
Hi,
  
  I think I solved this issue by 
  
  #ifdef WITH_WSREP
  if (!wsrep_emulate_bin_log)
      binlog_trans_log_truncate(thd, *(my_off_t*)sv);
  #endif
  
  This avoids using the uninitialized memory in Galera, this was
  error in merge.
  
  R: Jan
   


  seppo.jaak...@codership.com writes:


  
Did I understand it right that the problem is with "ROLLBACK TO
SAVEPOINT...", where the designated savepoint does not exist? Did you

  
  
No. It is a very simple issue.

The beginning of binlog_savepoint_set() reads:

#ifdef WITH_WSREP
  if (wsrep_emulate_bin_log) DBUG_RETURN(0);
#endif /* WITH_WSREP */

So binlog_savepoint_set() does nothing in the Galera case.

But binlog_savepoint_rollback() reads:

#ifdef WITH_WSREP
  if (!wsrep_emulate_bin_log ...
#endif
  {
...
  }

  binlog_trans_log_truncate(thd, *(my_off_t*)sv);

Note that the binlog_trans_log_truncate() call is outside the if, so it _is_
executed even in the Galera case.

So the WSREP patch tries to disable some binlog savepoint code but does it
incorrectly. It disables setting the savepoint but not rolling it back, so the
latter gets invalid data. It needs to match up, so that _set() and _rollback()
match each other in what they do.

This issue is in the maria-10.0-galera tree. I did not check other Galera
trees (not sure which trees to check).

 - Kristian.

___
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




-- 
  --
  Jan Lindström
Principal Engineer
  
  MariaDB | MaxScale | skype: jan_p_lindstrom
  www.skysql.com
  

  

___
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] [GSoC] Request for code review

[QIU Shuang]

Hi Sergei,

> Do you have a tree on launchpad with your code?
Yes, I have. Here is the URL to my branch: 
https://code.launchpad.net/~qiush-summer/maria/krb_auth_plugin.

> Then the easiest way would be to propose a merge of your tree into
> mariadb. See https://help.launchpad.net/Code/Review
I've submitted my merging proposal following the instructions step by step 
while leaving the requested reviewer empty, since I don't know who are experts 
in community on this topic.
Thank you if you could help :).

> Besides you should submit the MCA or put your code under a New BSD
> License before the review, not after.
I'll send the MCA later soon to the community.

Thank you for your time and concern and best regards!
Sincerely, Shuang


On Sep 27, 2013, at 9:18 PM, Sergei Golubchik  wrote:

> Hi, QIU!
> 
> On Sep 27, QIU Shuang wrote:
>> This is Shuang, a participant for GSoC 2013 Kerberize MariaDB project.
>> I want to ask the community to review the code before requesting for
>> pull and send the MCA.
>> How could I send the codes? In a diff file? or from other approaches?
> 
> Do you have a tree on launchpad with your code?
> Then the easiest way would be to propose a merge of your tree into
> mariadb. See https://help.launchpad.net/Code/Review
> 
> Besides you should submit the MCA or put your code under a New BSD
> License before the review, not after.
> 
> 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] Questions re MDEV-4736 and MDEV-4739 (was Re: Spider's installation sql file)

[kentoku]

Hi Sergey,

> > > The above should have been fixed back in the beginning of 2012. Which
> > MariaDB
> > revision are you testing with?
> > It's same as lp:~kentokushiba/maria/10.0.4-spider-3.0.
> That's very strange. How did you build it and what command line options
did
> you use (including those that are listed in my.cnf)?
O.K. I send you later.

> > By the way, I found a problem point in Spider. Currently it is fixed and
> > pushed. And I can't reproduce assertion failure. Can you reproduce this
> > failure yet?
> I just tested 10.0.4-spider-3.0 with rev.3827, it still fails.
Could you please tell me about build options and command line options that
you used?

Thanks,
Kentoku



2013/9/27 Sergey Vojtovich 

> Hi Kentoku,
>
> On Wed, Sep 25, 2013 at 02:53:17AM +0900, kentoku wrote:
> > Hi Sergey,
> >
> > > The above should have been fixed back in the beginning of 2012. Which
> > MariaDB
> > revision are you testing with?
> > It's same as lp:~kentokushiba/maria/10.0.4-spider-3.0.
> That's very strange. How did you build it and what command line options did
> you use (including those that are listed in my.cnf)?
>
> > By the way, I found a problem point in Spider. Currently it is fixed and
> > pushed. And I can't reproduce assertion failure. Can you reproduce this
> > failure yet?
> I just tested 10.0.4-spider-3.0 with rev.3827, it still fails.
>
> Regards,
> Sergey
>
> >
> > Thanks,
> > Kentoku
> >
> >
> >
> >
> > 2013/9/24 Sergey Vojtovich 
> >
> > > Hi Kentoku,
> > >
> > > On Thu, Sep 19, 2013 at 11:47:33PM +0900, kentoku wrote:
> > > > Hi Sergey,
> > > >
> > > > > I'm afraid fixing rnd_end() callers in the server may stall for a
> long
> > > > time.
> > > > O.K. No need to fix it if it is not easy. This request is not high
> > > priority
> > > > request.
> > > >
> > > > > Is it accaptable for spider to use bulk updates and deletes API
> instead
> > > > > (see handler.h: start_bulk_update/start_bulk_delete).
> > > > Spider use it already. This API is not used if target table has after
> > > > trigger. I understand why this API is not used in this case, but it
> > > > sometimes causes performance problem. So, I thought it is better to
> > > prepare
> > > > other choice for something wrong. Anyway, I will disable bulk
> > > > updating/deleting feature without using API.
> > > I see. Hope it is acceptable.
> > >
> > > >
> > > > > Nope, it looks like a bug in thread pool. MDEV-4739 has different
> > > trace,
> > > > how
> > > > did you get this one? Just executed given test?
> > > > I got this trace when I try to reproduce MDEV-4739. I did as the
> > > followings.
> > > >
> > > > 1. start mysqld
> > > > 2. log in mysqld
> > > > 3. mysql> CREATE TABLE t1 (a INT) ENGINE=InnoDB;
> > > > 4. mysql> XA START 'xa1';
> > > > 5. mysql> INSERT INTO t1 (a) VALUES (1),(2);
> > > > 6. mysql> XA END 'xa1';
> > > > 7. mysql> XA PREPARE 'xa1';
> > > > 8. kill -9 mysqld_safe and mysqld from another terminal
> > > > 9. start mysqld on gdb
> > > >
> > > > At that time, InnoDB and Spider were enabled and log-bin was
> disabled. So
> > > > probably "total_ha_2pc > 1" was true, "opt_bin_log" was false.
> > > > Does it help you?
> > > We couldn't reproduce it yet. :(
> > >
> > > Looking through the code I noticed that call to thd_wait_begin() looks
> as
> > > following:
> > >
> > > static void scheduler_wait_sync_begin(void) {
> > >   thd_wait_begin(NULL, THD_WAIT_SYNC);
> > > }
> > >
> > > Note that thd is always NULL. And it must be NULL at this point,
> because
> > > we're
> > > booting. But according to your trace thd is not NULL.
> > >
> > > #0  0x005eabf6 in thd_wait_begin (
> > > thd=0x29da060, wait_type=10)
> > > at /ssd1/mariadb-10.0.4/sql/sql_class.cc:4277
> > > #1  0x0072a114 in scheduler_wait_sync_begin ()
> > > at /ssd1/mariadb-10.0.4/sql/scheduler.cc:59
> > > ...
> > >
> > > The above should have been fixed back in the beginning of 2012. Which
> > > MariaDB
> > > revision are you testing with?
> > >
> > > Thanks,
> > > Sergey
> > >
> > >
> > >
> > > >
> > > > Thanks,
> > > > Kentoku
> > > >
> > > >
> > > >
> > > > 2013/9/19 Sergey Vojtovich 
> > > >
> > > > > Hi Kentoku,
> > > > >
> > > > > I'm adding MariaDB developers to CC.
> > > > >
> > > > > On Thu, Sep 19, 2013 at 01:19:13AM +0900, kentoku wrote:
> > > > > > Hi Sergey,
> > > > > >
> > > > > > > But what kind of errors are possible in your case? Other
> storage
> > > > > engines
> > > > > > doesn't
> > > > > > seem to suffer from this API violation.
> > > > > >
> > > > > > Spider support bulk updating and deleting for avoiding network
> > > roundtrip
> > > > > > between data node. Some times, last bulk updating is executed in
> > > > > rnd_end()
> > > > > > function. So rnd_end() has possibility getting errors from data
> node.
> > > > > I'm afraid fixing rnd_end() callers in the server may stall for a
> long
> > > > > time.
> > > > > Is it accaptable for spider to use bulk updates and deletes API
> instead
> > > > > (see handler.h: s

[Maria-developers] [GSoC] MariaDB Contributor Agreement for Kerberos Authentication Plugin

[QIU Shuang]

Hi community,

I declare that all the work done so far (and future) on the project Kerberize 
MariaDB is licenced by the new BSD Lisence.

Please contact me if any problems with the license.

Thank you all and best regards!
Sincerely, Shuang___
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] Questions re MDEV-4736 and MDEV-4739 (was Re: Spider's installation sql file)

[Sergey Vojtovich]

Hi Kentoku,

BUILD/compile-amd64-debug-max
cd mysql-test
cat > t/AAA.test
--source include/have_innodb.inc

install soname 'ha_spider.so';

--connection default
eval CREATE TABLE t1 (a INT) ENGINE=InnoDB;

--connect (con1,localhost,root,,)
XA START 'xa1';
INSERT INTO t1 (a) VALUES (1),(2);
XA END 'xa1';
XA PREPARE 'xa1';

--connection default
--enable_reconnect
--append_file $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
restart
EOF
--shutdown_server 0
--source include/wait_until_disconnected.inc
--source include/wait_until_connected_again.inc
XA RECOVER;
XA COMMIT 'xa1';
--End of file
./mtr AAA

Regards,
Sergey

On Fri, Sep 27, 2013 at 11:21:01PM +0900, kentoku wrote:
> Hi Sergey,
> 
> > > > The above should have been fixed back in the beginning of 2012. Which
> > > MariaDB
> > > revision are you testing with?
> > > It's same as lp:~kentokushiba/maria/10.0.4-spider-3.0.
> > That's very strange. How did you build it and what command line options
> did
> > you use (including those that are listed in my.cnf)?
> O.K. I send you later.
> 
> > > By the way, I found a problem point in Spider. Currently it is fixed and
> > > pushed. And I can't reproduce assertion failure. Can you reproduce this
> > > failure yet?
> > I just tested 10.0.4-spider-3.0 with rev.3827, it still fails.
> Could you please tell me about build options and command line options that
> you used?
> 
> Thanks,
> Kentoku
> 
> 
> 
> 2013/9/27 Sergey Vojtovich 
> 
> > Hi Kentoku,
> >
> > On Wed, Sep 25, 2013 at 02:53:17AM +0900, kentoku wrote:
> > > Hi Sergey,
> > >
> > > > The above should have been fixed back in the beginning of 2012. Which
> > > MariaDB
> > > revision are you testing with?
> > > It's same as lp:~kentokushiba/maria/10.0.4-spider-3.0.
> > That's very strange. How did you build it and what command line options did
> > you use (including those that are listed in my.cnf)?
> >
> > > By the way, I found a problem point in Spider. Currently it is fixed and
> > > pushed. And I can't reproduce assertion failure. Can you reproduce this
> > > failure yet?
> > I just tested 10.0.4-spider-3.0 with rev.3827, it still fails.
> >
> > Regards,
> > Sergey
> >
> > >
> > > Thanks,
> > > Kentoku
> > >
> > >
> > >
> > >
> > > 2013/9/24 Sergey Vojtovich 
> > >
> > > > Hi Kentoku,
> > > >
> > > > On Thu, Sep 19, 2013 at 11:47:33PM +0900, kentoku wrote:
> > > > > Hi Sergey,
> > > > >
> > > > > > I'm afraid fixing rnd_end() callers in the server may stall for a
> > long
> > > > > time.
> > > > > O.K. No need to fix it if it is not easy. This request is not high
> > > > priority
> > > > > request.
> > > > >
> > > > > > Is it accaptable for spider to use bulk updates and deletes API
> > instead
> > > > > > (see handler.h: start_bulk_update/start_bulk_delete).
> > > > > Spider use it already. This API is not used if target table has after
> > > > > trigger. I understand why this API is not used in this case, but it
> > > > > sometimes causes performance problem. So, I thought it is better to
> > > > prepare
> > > > > other choice for something wrong. Anyway, I will disable bulk
> > > > > updating/deleting feature without using API.
> > > > I see. Hope it is acceptable.
> > > >
> > > > >
> > > > > > Nope, it looks like a bug in thread pool. MDEV-4739 has different
> > > > trace,
> > > > > how
> > > > > did you get this one? Just executed given test?
> > > > > I got this trace when I try to reproduce MDEV-4739. I did as the
> > > > followings.
> > > > >
> > > > > 1. start mysqld
> > > > > 2. log in mysqld
> > > > > 3. mysql> CREATE TABLE t1 (a INT) ENGINE=InnoDB;
> > > > > 4. mysql> XA START 'xa1';
> > > > > 5. mysql> INSERT INTO t1 (a) VALUES (1),(2);
> > > > > 6. mysql> XA END 'xa1';
> > > > > 7. mysql> XA PREPARE 'xa1';
> > > > > 8. kill -9 mysqld_safe and mysqld from another terminal
> > > > > 9. start mysqld on gdb
> > > > >
> > > > > At that time, InnoDB and Spider were enabled and log-bin was
> > disabled. So
> > > > > probably "total_ha_2pc > 1" was true, "opt_bin_log" was false.
> > > > > Does it help you?
> > > > We couldn't reproduce it yet. :(
> > > >
> > > > Looking through the code I noticed that call to thd_wait_begin() looks
> > as
> > > > following:
> > > >
> > > > static void scheduler_wait_sync_begin(void) {
> > > >   thd_wait_begin(NULL, THD_WAIT_SYNC);
> > > > }
> > > >
> > > > Note that thd is always NULL. And it must be NULL at this point,
> > because
> > > > we're
> > > > booting. But according to your trace thd is not NULL.
> > > >
> > > > #0  0x005eabf6 in thd_wait_begin (
> > > > thd=0x29da060, wait_type=10)
> > > > at /ssd1/mariadb-10.0.4/sql/sql_class.cc:4277
> > > > #1  0x0072a114 in scheduler_wait_sync_begin ()
> > > > at /ssd1/mariadb-10.0.4/sql/scheduler.cc:59
> > > > ...
> > > >
> > > > The above should have been fixed back in the beginning of 2012. Which
> > > > MariaDB
> > > > revision are you testing with?
> > > >
> > > > Thanks,
> > > > Sergey
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > >

[Maria-developers] EXPLAIN INSERT in MySQL - not useful after all?

[Sergei Petrunia]

Hi,

Among the topics of yesterday's optimizer call was the question of what is the
point of EXPLAIN INSERT. The point was that INSERT doesn't need a query plan.
Somebody has mentioned that perhaps, EXPLAIN INSERT could show results of
partition pruning.

This doesn't seem to be the case:


5.6.14-debug
MySQL [test]> explain partitions insert into t1p values (2,2);
++-+---++--+---+--+-+--+--++
| id | select_type | table | partitions | type | possible_keys | key  | key_len 
| ref  | rows | Extra  |
++-+---++--+---+--+-+--+--++
|  1 | SIMPLE  | NULL  | NULL   | NULL | NULL  | NULL | NULL
| NULL | NULL | No tables used |
++-+---++--+---+--+-+--+--++
1 row in set (1.34 sec)


5.7.2-m12-debug:
MySQL [test]> explain partitions insert into t1p values (1,1);
++-+---+-+--+---+--+-+--+--+---+
| id | select_type | table | partitions  | type | possible_keys | key  | 
key_len | ref  | rows | Extra |
++-+---+-+--+---+--+-+--+--+---+
|  1 | INSERT  | t1p   | p0,p1,p2,p3 | ALL  | NULL  | NULL | NULL   
 | NULL | NULL | NULL  |
++-+---+-+--+---+--+-+--+--+---+
1 row in set (0.00 sec)


That is, EXPLAIN in 5.7 looks a bit more meaningful, but it still doesn't show 
results of partition pruning.

The table t1p is partitioned, it was created as follows:

create table t1(a int);
insert into t1 values (1),(2),(3),(4);
create table t1p (a int, b int) partition by hash(a) partitions 4;
insert into t1p select * from t1;

that is, values (1,1) should have allowed to pick the partition to use, or it
wasn't done.

So, is EXPLAIN INSERT meaningles, or I am missing something here?


BR
 Sergei
--

Sergei Petrunia, Software Developer
MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog



___
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] EXPLAIN INSERT in MySQL - not useful after all?

[Jean Weisbuch]

Could it be of use for the INSERT ... SELECT ... queries?

Sergei Petrunia  wrote:
>Hi,
>
>Among the topics of yesterday's optimizer call was the question of what
>is the
>point of EXPLAIN INSERT. The point was that INSERT doesn't need a query
>plan.
>Somebody has mentioned that perhaps, EXPLAIN INSERT could show results
>of
>partition pruning.
>
>This doesn't seem to be the case:
>
>
>5.6.14-debug
>MySQL [test]> explain partitions insert into t1p values (2,2);
>++-+---++--+---+--+-+--+--++
>| id | select_type | table | partitions | type | possible_keys | key  |
>key_len | ref  | rows | Extra  |
>++-+---++--+---+--+-+--+--++
>|  1 | SIMPLE  | NULL  | NULL   | NULL | NULL  | NULL |
>NULL| NULL | NULL | No tables used |
>++-+---++--+---+--+-+--+--++
>1 row in set (1.34 sec)
>
>
>5.7.2-m12-debug:
>MySQL [test]> explain partitions insert into t1p values (1,1);
>++-+---+-+--+---+--+-+--+--+---+
>| id | select_type | table | partitions  | type | possible_keys | key
>| key_len | ref  | rows | Extra |
>++-+---+-+--+---+--+-+--+--+---+
>|  1 | INSERT  | t1p   | p0,p1,p2,p3 | ALL  | NULL  | NULL
>| NULL| NULL | NULL | NULL  |
>++-+---+-+--+---+--+-+--+--+---+
>1 row in set (0.00 sec)
>
>
>That is, EXPLAIN in 5.7 looks a bit more meaningful, but it still
>doesn't show
>results of partition pruning.
>
>The table t1p is partitioned, it was created as follows:
>
>create table t1(a int);
>insert into t1 values (1),(2),(3),(4);
>create table t1p (a int, b int) partition by hash(a) partitions 4;
>insert into t1p select * from t1;
>
>that is, values (1,1) should have allowed to pick the partition to use,
>or it
>wasn't done.
>
>So, is EXPLAIN INSERT meaningles, or I am missing something here?
>
>
>BR
> Sergei
>--
>
>Sergei Petrunia, Software Developer
>MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog
>
>
>
>___
>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] EXPLAIN INSERT in MySQL - not useful after all?

[Giuseppe Maxia]

It looks like a bug.The partition pruning kicks just fine for UPDATEsshow create table t2p\G*** 1. row ***       Table: t2pCreate Table: CREATE TABLE `t2p` (  `a` int(11) DEFAULT NULL,  `b` int(11) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=latin1/*!50100 PARTITION BY RANGE (a)(PARTITION p001 VALUES LESS THAN (11) ENGINE = InnoDB, PARTITION p002 VALUES LESS THAN (21) ENGINE = InnoDB, PARTITION p003 VALUES LESS THAN (31) ENGINE = InnoDB, PARTITION p004 VALUES LESS THAN (41) ENGINE = InnoDB, PARTITION p005 VALUES LESS THAN (51) ENGINE = InnoDB, PARTITION p006 VALUES LESS THAN (61) ENGINE = InnoDB, PARTITION p007 VALUES LESS THAN (71) ENGINE = InnoDB, PARTITION p008 VALUES LESS THAN (81) ENGINE = InnoDB, PARTITION p009 VALUES LESS THAN (91) ENGINE = InnoDB, PARTITION p010 VALUES LESS THAN (101) ENGINE = InnoDB) */1 row in set (0.01 sec)explain partitions update   t2p set b = 38 where a = 30\G*** 1. row ***           id: 1  select_type: UPDATE        table: t2p   partitions: p003         type: ALLpossible_keys: NULL          key: NULL      key_len: NULL          ref: NULL         rows: 2        Extra: Using whereexplain partitions insert into t2p set a=45, b = 20 \G*** 1. row ***           id: 1  select_type: INSERT        table: t2p   partitions: p001,p002,p003,p004,p005,p006,p007,p008,p009,p010         type: ALLpossible_keys: NULL          key: NULL      key_len: NULL          ref: NULL         rows: NULL        Extra: NULL On September 27, 2013 at 09:18:19 , Sergei Petrunia (pser...@askmonty.org) wrote: Hi,

Among the topics of yesterday's optimizer call was the question of what is the
point of EXPLAIN INSERT. The point was that INSERT doesn't need a query plan.
Somebody has mentioned that perhaps, EXPLAIN INSERT could show results of
partition pruning.

This doesn't seem to be the case:


5.6.14-debug
MySQL [test]> explain partitions insert into t1p values (2,2);
++-+---++--+---+--+-+--+--++
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | Extra  |
++-+---++--+---+--+-+--+--++
|  1 | SIMPLE  | NULL  | NULL   | NULL | NULL  | NULL | NULL| NULL | NULL | No tables used |
++-+---++--+---+--+-+--+--++
1 row in set (1.34 sec)


5.7.2-m12-debug:
MySQL [test]> explain partitions insert into t1p values (1,1);
++-+---+-+--+---+--+-+--+--+---+
| id | select_type | table | partitions  | type | possible_keys | key  | key_len | ref  | rows | Extra |
++-+---+-+--+---+--+-+--+--+---+
|  1 | INSERT  | t1p   | p0,p1,p2,p3 | ALL  | NULL  | NULL | NULL| NULL | NULL | NULL  |
++-+---+-+--+---+--+-+--+--+---+
1 row in set (0.00 sec)


That is, EXPLAIN in 5.7 looks a bit more meaningful, but it still doesn't show  
results of partition pruning.

The table t1p is partitioned, it was created as follows:

create table t1(a int);
insert into t1 values (1),(2),(3),(4);
create table t1p (a int, b int) partition by hash(a) partitions 4;
insert into t1p select * from t1;

that is, values (1,1) should have allowed to pick the partition to use, or it
wasn't done.

So, is EXPLAIN INSERT meaningles, or I am missing something here?


BR
 Sergei
--

Sergei Petrunia, Software Developer
MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog



___
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] EXPLAIN INSERT in MySQL - not useful after all?

[Sergei Petrunia]

I agree that for INSERT .. SELECT, EXPLAIN is useful - it shows query plan of 
the SELECT part.

I was wondering specifically about the INSERT ... VALUES (...) syntax. I was
just checking EXPLAIN in Maria vs EXPLAIN in MySQL, and could not find what is
the rationale for EXPLAIN INSERT ... VALUES.

On Fri, Sep 27, 2013 at 06:22:09PM +0200, Jean Weisbuch wrote:
> Could it be of use for the INSERT ... SELECT ... queries?
> 
> Sergei Petrunia  wrote:
> >Hi,
> >
> >Among the topics of yesterday's optimizer call was the question of what
> >is the
> >point of EXPLAIN INSERT. The point was that INSERT doesn't need a query
> >plan.
> >Somebody has mentioned that perhaps, EXPLAIN INSERT could show results
> >of
> >partition pruning.
> >
> >This doesn't seem to be the case:
> >
> >
> >5.6.14-debug
> >MySQL [test]> explain partitions insert into t1p values (2,2);
> >++-+---++--+---+--+-+--+--++
> >| id | select_type | table | partitions | type | possible_keys | key  |
> >key_len | ref  | rows | Extra  |
> >++-+---++--+---+--+-+--+--++
> >|  1 | SIMPLE  | NULL  | NULL   | NULL | NULL  | NULL |
> >NULL| NULL | NULL | No tables used |
> >++-+---++--+---+--+-+--+--++
> >1 row in set (1.34 sec)
> >
> >
> >5.7.2-m12-debug:
> >MySQL [test]> explain partitions insert into t1p values (1,1);
> >++-+---+-+--+---+--+-+--+--+---+
> >| id | select_type | table | partitions  | type | possible_keys | key
> >| key_len | ref  | rows | Extra |
> >++-+---+-+--+---+--+-+--+--+---+
> >|  1 | INSERT  | t1p   | p0,p1,p2,p3 | ALL  | NULL  | NULL
> >| NULL| NULL | NULL | NULL  |
> >++-+---+-+--+---+--+-+--+--+---+
> >1 row in set (0.00 sec)
> >
> >
> >That is, EXPLAIN in 5.7 looks a bit more meaningful, but it still
> >doesn't show
> >results of partition pruning.
> >
> >The table t1p is partitioned, it was created as follows:
> >
> >create table t1(a int);
> >insert into t1 values (1),(2),(3),(4);
> >create table t1p (a int, b int) partition by hash(a) partitions 4;
> >insert into t1p select * from t1;
> >
> >that is, values (1,1) should have allowed to pick the partition to use,
> >or it
> >wasn't done.
> >
> >So, is EXPLAIN INSERT meaningles, or I am missing something here?
> >
> >
> >BR
> > Sergei
> >--
> >
> >Sergei Petrunia, Software Developer
> >MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog
> >
> >
> >
> >___
> >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


-- 
BR
 Sergei
--

Sergei Petrunia, Software Developer
MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog



___
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] MySQL bug affects mariaDB

[Vladislav Vaintroub]

The command line clients are not services, and they are not started with 
--defaults-file, this is correct.

 

But

 

1.We install shortcut to mysql client and shortcut does have  --defaults-file , 
and the default-file points to the right place, i.e whenever you installed the 
mysql server instance

On my machine (I used the default x64 installation), MySQL client shortcut is  
this

 

C:\Windows\System32\cmd.exe /k " "C:\Program Files\MariaDB 5.5\bin\mysql.exe" 
"--defaults-file=C:\Program Files\MariaDB 5.5\data\my.ini" -uroot -p"”

 

2. Out installation also provides another shortcut – called Command Prompt( 
MariaDB …)

It could be used to call arbitrary client utilities, mysqladmin or somesuch .It 
uses yet another,  less known, trick to force client utilities to look for 
correct my.ini - it sets environment variable MYSQL_HOME to point to the the 
datadir  ( Besides, it also sets PATH to include “bin” directory, so that 
calling mysqladmin or mysql would not result in “path not found”)

 

The inspiration for this shortcut was a very similar feature of Visual Studio , 
the “Visual Studio 20xx Command Line”.

 

The summary of my.ini client-side support is that :

If you install with MSI,  installer will create  shortcuts that help client 
utilities to find correct my.ini . You can have multiple versions of the 
MariaDB installed, and the shortcuts will still work correctly – every version 
specific shortcut would point to version-specific my.ini

 

Thus, I’d argue that this bug does not affect MariaDB.

 

 

 

From: Maria-developers 
[mailto:maria-developers-bounces+wlad=montyprogram@lists.launchpad.net] On 
Behalf Of Peter Laursen
Sent: Freitag, 27. September 2013 10:06
To: Maria Developers; Maria Discuss
Subject: [Maria-developers] MySQL bug affects mariaDB

 

 

I think the 'mysql' client with MariaDB has a similar problem as it has with 
MySQL - refer?

http://bugs.mysql.com/bug.php?id=70443

 

MariaDB installer installs my.ini to /datadir - what with MariaDB is a 
subfolder to /basedir. 

 

The server will look for it correctly as the registry key defining the service 
has a --default-file specification.  But the command line clients don't read 
the registry key.

 

 

@Wlad?

 

 

-- Peter

-- Webyog

 

 

___
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] MySQL bug affects mariaDB

[Peter Laursen]

Thanks wlad for explanation, but this applies to 'shortcuts' (in start
menu) only I think, as I understand your reply.

If I navigate ('cd ..') to the /datadir where my.ini resides and launch
'mysql' from commnd line I will need to specify --defaults-file on the
command line, right? If not the client will start with defaults (or it will
use whatever other my.ini it finds in C:\, C:\Windows or /basedir).

?


-- Peter


On Fri, Sep 27, 2013 at 7:06 PM, Vladislav Vaintroub
wrote:

> The command line clients are not services, and they are not started with
> --defaults-file, this is correct.
>
> ** **
>
> But
>
> ** **
>
> 1.We install shortcut to mysql client and shortcut does have
>  --defaults-file , and the default-file points to the right place, i.e
> whenever you installed the mysql server instance
>
> On my machine (I used the default x64 installation), MySQL client shortcut
> is  this
>
> ** **
>
> C:\Windows\System32\cmd.exe /k " "C:\Program Files\MariaDB
> 5.5\bin\mysql.exe" "--defaults-file=C:\Program Files\MariaDB
> 5.5\data\my.ini" -uroot -p"”
>
> ** **
>
> 2. Out installation also provides another shortcut – called Command
> Prompt( MariaDB …)
>
> It could be used to call arbitrary client utilities, mysqladmin or
> somesuch .It uses yet another,  less known, trick to force client utilities
> to look for correct my.ini - it sets environment variable MYSQL_HOME to
> point to the the datadir  ( Besides, it also sets PATH to include “bin”
> directory, so that calling mysqladmin or mysql would not result in “path
> not found”)
>
> ** **
>
> The inspiration for this shortcut was a very similar feature of Visual
> Studio , the “Visual Studio 20xx Command Line”.
>
> ** **
>
> The summary of my.ini client-side support is that :
>
> If you install with MSI,  installer will create  shortcuts that help
> client utilities to find correct my.ini . You can have multiple versions of
> the MariaDB installed, and the shortcuts will still work correctly – every
> version specific shortcut would point to version-specific my.ini
>
> ** **
>
> Thus, I’d argue that this bug does not affect MariaDB.
>
> 
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Maria-developers [mailto:maria-developers-bounces+wlad=
> montyprogram@lists.launchpad.net] *On Behalf Of *Peter Laursen
> *Sent:* Freitag, 27. September 2013 10:06
> *To:* Maria Developers; Maria Discuss
> *Subject:* [Maria-developers] MySQL bug affects mariaDB
>
> ** **
>
> ** **
>
> I think the 'mysql' client with MariaDB has a similar problem as it has
> with MySQL - refer?
>
> http://bugs.mysql.com/bug.php?id=70443
>
> ** **
>
> MariaDB installer installs my.ini to /datadir - what with MariaDB is a
> subfolder to /basedir. 
>
> ** **
>
> The server will look for it correctly as the registry key defining the
> service has a --default-file specification.  But the command line clients
> don't read the registry key.
>
> ** **
>
> ** **
>
> @Wlad?
>
> ** **
>
> ** **
>
> -- Peter
>
> -- Webyog
>
> ** **
>
> ** **
>
___
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] [Maria-discuss] MySQL bug affects mariaDB

[Vladislav Vaintroub]

Justin, I appreciate your opinion, and if MySQL on Windows would not support 
multiple versions running on the same machine, I would agree. 

But since we (and/or generations of programmers before me) chose to support 
multiple version of MySQL coexisting on the same machine, and I did not want to 
break it, I see no real alternative.   

 

 

From: Justin Swanhart [mailto:greenl...@gmail.com] 
Sent: Freitag, 27. September 2013 19:54
To: Vladislav Vaintroub
Cc: Peter Laursen; Maria Developers; Maria Discuss
Subject: Re: [Maria-discuss] [Maria-developers] MySQL bug affects mariaDB

 

Please ignore wrong block quote here - stupid mail on iPhone won't paste 
without it

You know, windows does have easy ways to change the path and add variables to 
the environment without forcing shell invocation.  It is just that in the case 
of VS you might cross-compile or choose to compile with Vs2008 or vs2012 as 
they can be installed simultaneously.  I think if you are creating a service 
(in windows parlance) the client should know how to connect to the service sans 
hoops. Just my opinion...  VS is not the way most windows programs do things 
and you should not violate the principal if least surprise.





--Justin


On Sep 27, 2013, at 1:06 PM, "Vladislav Vaintroub"  
wrote:

The command line clients are not services, and they are not started with 
--defaults-file, this is correct.

 

But

 

1.We install shortcut to mysql client and shortcut does have  --defaults-file , 
and the default-file points to the right place, i.e whenever you installed the 
mysql server instance

On my machine (I used the default x64 installation), MySQL client shortcut is  
this

 

C:\Windows\System32\cmd.exe /k " "C:\Program Files\MariaDB 5.5\bin\mysql.exe" 
"--defaults-file=C:\Program Files\MariaDB 5.5\data\my.ini" -uroot -p"”

 

2. Out installation also provides another shortcut – called Command Prompt( 
MariaDB …)

It could be used to call arbitrary client utilities, mysqladmin or somesuch .It 
uses yet another,  less known, trick to force client utilities to look for 
correct my.ini - it sets environment variable MYSQL_HOME to point to the the 
datadir  ( Besides, it also sets PATH to include “bin” directory, so that 
calling mysqladmin or mysql would not result in “path not found”)

 

The inspiration for this shortcut was a very similar feature of Visual Studio , 
the “Visual Studio 20xx Command Line”.

 

The summary of my.ini client-side support is that :

If you install with MSI,  installer will create  shortcuts that help client 
utilities to find correct my.ini . You can have multiple versions of the 
MariaDB installed, and the shortcuts will still work correctly – every version 
specific shortcut would point to version-specific my.ini

 

Thus, I’d argue that this bug does not affect MariaDB.

 

 

 

From: Maria-developers 
[mailto:maria-developers-bounces+wlad=montyprogram@lists.launchpad.net] On 
Behalf Of Peter Laursen
Sent: Freitag, 27. September 2013 10:06
To: Maria Developers; Maria Discuss
Subject: [Maria-developers] MySQL bug affects mariaDB

 

 

I think the 'mysql' client with MariaDB has a similar problem as it has with 
MySQL - refer?

  http://bugs.mysql.com/bug.php?id=70443

 

MariaDB installer installs my.ini to /datadir - what with MariaDB is a 
subfolder to /basedir. 

 

The server will look for it correctly as the registry key defining the service 
has a --default-file specification.  But the command line clients don't read 
the registry key.

 

 

@Wlad?

 

 

-- Peter

-- Webyog

 

 

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-disc...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
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] MySQL bug affects mariaDB

[Vladislav Vaintroub]

Current directory does not play any role in choosing defaults file. You indeed 
need either to specify –defauilts-file, or set MYSQL_HOME, or the bdefault 
logic of finding my.ini will apply 

On the other hand, I rarely find myself in need to use my.ini for clients. In 
doubt, I provide –port , and that’s all I need for the command line clients

 

From: Peter Laursen [mailto:peter_laur...@webyog.com] 
Sent: Freitag, 27. September 2013 19:15
To: Vladislav Vaintroub
Cc: Maria Developers; Maria Discuss
Subject: Re: [Maria-developers] MySQL bug affects mariaDB

 

Thanks wlad for explanation, but this applies to 'shortcuts' (in start menu) 
only I think, as I understand your reply.  

 

If I navigate ('cd ..') to the /datadir where my.ini resides and launch 'mysql' 
from commnd line I will need to specify --defaults-file on the command line, 
right? If not the client will start with defaults (or it will use whatever 
other my.ini it finds in C:\, C:\Windows or /basedir).

 

?

 

 

-- Peter

 

On Fri, Sep 27, 2013 at 7:06 PM, Vladislav Vaintroub  
wrote:

The command line clients are not services, and they are not started with 
--defaults-file, this is correct.

 

But

 

1.We install shortcut to mysql client and shortcut does have  --defaults-file , 
and the default-file points to the right place, i.e whenever you installed the 
mysql server instance

On my machine (I used the default x64 installation), MySQL client shortcut is  
this

 

C:\Windows\System32\cmd.exe /k " "C:\Program Files\MariaDB 5.5\bin\mysql.exe" 
"--defaults-file=C:\Program Files\MariaDB 5.5\data\my.ini" -uroot -p"”

 

2. Out installation also provides another shortcut – called Command Prompt( 
MariaDB …)

It could be used to call arbitrary client utilities, mysqladmin or somesuch .It 
uses yet another,  less known, trick to force client utilities to look for 
correct my.ini - it sets environment variable MYSQL_HOME to point to the the 
datadir  ( Besides, it also sets PATH to include “bin” directory, so that 
calling mysqladmin or mysql would not result in “path not found”)

 

The inspiration for this shortcut was a very similar feature of Visual Studio , 
the “Visual Studio 20xx Command Line”.

 

The summary of my.ini client-side support is that :

If you install with MSI,  installer will create  shortcuts that help client 
utilities to find correct my.ini . You can have multiple versions of the 
MariaDB installed, and the shortcuts will still work correctly – every version 
specific shortcut would point to version-specific my.ini

 

Thus, I’d argue that this bug does not affect MariaDB.

 

 

 

From: Maria-developers [mailto:maria-developers-bounces+wlad 
 =montyprogram@lists.launchpad.net] 
On Behalf Of Peter Laursen
Sent: Freitag, 27. September 2013 10:06
To: Maria Developers; Maria Discuss
Subject: [Maria-developers] MySQL bug affects mariaDB

 

 

I think the 'mysql' client with MariaDB has a similar problem as it has with 
MySQL - refer?

http://bugs.mysql.com/bug.php?id=70443

 

MariaDB installer installs my.ini to /datadir - what with MariaDB is a 
subfolder to /basedir. 

 

The server will look for it correctly as the registry key defining the service 
has a --default-file specification.  But the command line clients don't read 
the registry key.

 

 

@Wlad?

 

 

-- Peter

-- Webyog

 

 

 

___
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] [Maria-discuss] MySQL bug affects mariaDB

[Peter Laursen]

On Windows multiple MySQL servers run (if only they have distinct basedir,
datadir, port (and/or pipe) and service name). This is how Windows manages
servides (daemons) simply!

And BTW: this is the reason why Windows is a comfortable platform for
application testing if you want to test an application that should work
with multiple MySQL server versions. Multiple MySQL servers on *nix is a
PITA - on Windows it is an ease as the OS has no restriction in this
respect.

-- Peter


On Fri, Sep 27, 2013 at 8:12 PM, Vladislav Vaintroub
wrote:

> Justin, I appreciate your opinion, and if MySQL on Windows would not
> support multiple versions running on the same machine, I would agree. 
>
> But since we (and/or generations of programmers before me) chose to
> support multiple version of MySQL coexisting on the same machine, and I did
> not want to break it, I see no real alternative.   
>
> ** **
>
> ** **
>
> *From:* Justin Swanhart [mailto:greenl...@gmail.com]
> *Sent:* Freitag, 27. September 2013 19:54
> *To:* Vladislav Vaintroub
> *Cc:* Peter Laursen; Maria Developers; Maria Discuss
> *Subject:* Re: [Maria-discuss] [Maria-developers] MySQL bug affects
> mariaDB
>
> ** **
>
> Please ignore wrong block quote here - stupid mail on iPhone won't paste
> without it
>
> You know, windows does have easy ways to change the path and add variables
> to the environment without forcing shell invocation.  It is just that in
> the case of VS you might cross-compile or choose to compile with Vs2008 or
> vs2012 as they can be installed simultaneously.  I think if you are
> creating a service (in windows parlance) the client should know how to
> connect to the service sans hoops. Just my opinion...  VS is not the way
> most windows programs do things and you should not violate the principal if
> least surprise.
>
>
>
> 
>
> --Justin
>
>
> On Sep 27, 2013, at 1:06 PM, "Vladislav Vaintroub" 
> wrote:
>
> The command line clients are not services, and they are not started with
> --defaults-file, this is correct.
>
>  
>
> But
>
>  
>
> 1.We install shortcut to mysql client and shortcut does have
>  --defaults-file , and the default-file points to the right place, i.e
> whenever you installed the mysql server instance
>
> On my machine (I used the default x64 installation), MySQL client shortcut
> is  this
>
>  
>
> C:\Windows\System32\cmd.exe /k " "C:\Program Files\MariaDB
> 5.5\bin\mysql.exe" "--defaults-file=C:\Program Files\MariaDB
> 5.5\data\my.ini" -uroot -p"”
>
>  
>
> 2. Out installation also provides another shortcut – called Command
> Prompt( MariaDB …)
>
> It could be used to call arbitrary client utilities, mysqladmin or
> somesuch .It uses yet another,  less known, trick to force client utilities
> to look for correct my.ini - it sets environment variable MYSQL_HOME to
> point to the the datadir  ( Besides, it also sets PATH to include “bin”
> directory, so that calling mysqladmin or mysql would not result in “path
> not found”)
>
>  
>
> The inspiration for this shortcut was a very similar feature of Visual
> Studio , the “Visual Studio 20xx Command Line”.
>
>  
>
> The summary of my.ini client-side support is that :
>
> If you install with MSI,  installer will create  shortcuts that help
> client utilities to find correct my.ini . You can have multiple versions of
> the MariaDB installed, and the shortcuts will still work correctly – every
> version specific shortcut would point to version-specific my.ini
>
>  
>
> Thus, I’d argue that this bug does not affect MariaDB.
>
>  
>
>  
>
>  
>
> *From:* Maria-developers [
> mailto:maria-developers-bounces+wlad=montyprogram@lists.launchpad.net
> ] *On Behalf Of *Peter Laursen
> *Sent:* Freitag, 27. September 2013 10:06
> *To:* Maria Developers; Maria Discuss
> *Subject:* [Maria-developers] MySQL bug affects mariaDB
>
>  
>
>  
>
> I think the 'mysql' client with MariaDB has a similar problem as it has
> with MySQL - refer?
>
> http://bugs.mysql.com/bug.php?id=70443
>
>  
>
> MariaDB installer installs my.ini to /datadir - what with MariaDB is a
> subfolder to /basedir. 
>
>  
>
> The server will look for it correctly as the registry key defining the
> service has a --default-file specification.  But the command line clients
> don't read the registry key.
>
>  
>
>  
>
> @Wlad?
>
>  
>
>  
>
> -- Peter
>
> -- Webyog
>
>  
>
>  
>
> ___
> Mailing list: https://launchpad.net/~maria-discuss
> Post to : maria-disc...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~maria-discuss
> 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-de

Re: [Maria-developers] MySQL bug affects mariaDB

[Peter Laursen]

"I rarely find myself in need to use my.ini for clients".  Not me either
except for max_allowed_packet (what is implemented in both server and
client) that user want to set to INSERT table rows with photographs (.jpg's
typically) to a table.

And the 'mysql' command line client has a default max_allowed_packet of 1MB
(in the server it was raised to 4MB in MySQL 5.6 - and if I remember right
it is 8MB in recent MariaDB - but I belive the client setting is still 1MB
even in MySQL 5.6 - I have not checked though).

In contrast the C-API (both Oracle's and MariaDB's) has a defaut of 1GB
(not sure about other connectors - such as JAVA and .NET). But I am not
aware of any GUI client compiling/linking the connector with client
max_allowed_packet lowered from 1GB (the highest possible value the
protocol allows for currently).


-- Peter


On Fri, Sep 27, 2013 at 8:19 PM, Vladislav Vaintroub
wrote:

> Current directory does not play any role in choosing defaults file. You
> indeed need either to specify –defauilts-file, or set MYSQL_HOME, or the
> bdefault logic of finding my.ini will apply 
>
> On the other hand, I rarely find myself in need to use my.ini for clients.
> In doubt, I provide –port , and that’s all I need for the command line
> clients
>
> ** **
>
> *From:* Peter Laursen [mailto:peter_laur...@webyog.com]
> *Sent:* Freitag, 27. September 2013 19:15
> *To:* Vladislav Vaintroub
> *Cc:* Maria Developers; Maria Discuss
> *Subject:* Re: [Maria-developers] MySQL bug affects mariaDB
>
> ** **
>
> Thanks wlad for explanation, but this applies to 'shortcuts' (in start
> menu) only I think, as I understand your reply.  
>
> ** **
>
> If I navigate ('cd ..') to the /datadir where my.ini resides and launch
> 'mysql' from commnd line I will need to specify --defaults-file on the
> command line, right? If not the client will start with defaults (or it will
> use whatever other my.ini it finds in C:\, C:\Windows or /basedir).
>
> ** **
>
> ?
>
> ** **
>
> ** **
>
> -- Peter
>
> ** **
>
> On Fri, Sep 27, 2013 at 7:06 PM, Vladislav Vaintroub <
> w...@montyprogram.com> wrote:
>
> The command line clients are not services, and they are not started with
> --defaults-file, this is correct.
>
>  
>
> But
>
>  
>
> 1.We install shortcut to mysql client and shortcut does have
>  --defaults-file , and the default-file points to the right place, i.e
> whenever you installed the mysql server instance
>
> On my machine (I used the default x64 installation), MySQL client shortcut
> is  this
>
>  
>
> C:\Windows\System32\cmd.exe /k " "C:\Program Files\MariaDB
> 5.5\bin\mysql.exe" "--defaults-file=C:\Program Files\MariaDB
> 5.5\data\my.ini" -uroot -p"”
>
>  
>
> 2. Out installation also provides another shortcut – called Command
> Prompt( MariaDB …)
>
> It could be used to call arbitrary client utilities, mysqladmin or
> somesuch .It uses yet another,  less known, trick to force client utilities
> to look for correct my.ini - it sets environment variable MYSQL_HOME to
> point to the the datadir  ( Besides, it also sets PATH to include “bin”
> directory, so that calling mysqladmin or mysql would not result in “path
> not found”)
>
>  
>
> The inspiration for this shortcut was a very similar feature of Visual
> Studio , the “Visual Studio 20xx Command Line”.
>
>  
>
> The summary of my.ini client-side support is that :
>
> If you install with MSI,  installer will create  shortcuts that help
> client utilities to find correct my.ini . You can have multiple versions of
> the MariaDB installed, and the shortcuts will still work correctly – every
> version specific shortcut would point to version-specific my.ini
>
>  
>
> Thus, I’d argue that this bug does not affect MariaDB.
>
>  
>
>  
>
>  
>
> *From:* Maria-developers [mailto:maria-developers-bounces+wlad=
> montyprogram@lists.launchpad.net] *On Behalf Of *Peter Laursen
> *Sent:* Freitag, 27. September 2013 10:06
> *To:* Maria Developers; Maria Discuss
> *Subject:* [Maria-developers] MySQL bug affects mariaDB
>
>  
>
>  
>
> I think the 'mysql' client with MariaDB has a similar problem as it has
> with MySQL - refer?
>
> http://bugs.mysql.com/bug.php?id=70443
>
>  
>
> MariaDB installer installs my.ini to /datadir - what with MariaDB is a
> subfolder to /basedir. 
>
>  
>
> The server will look for it correctly as the registry key defining the
> service has a --default-file specification.  But the command line clients
> don't read the registry key.
>
>  
>
>  
>
> @Wlad?
>
>  
>
>  
>
> -- Peter
>
> -- Webyog
>
>  
>
>  
>
> ** **
>
___
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