Hi,
>
> > Before you say they are fully compatible, I point out at least
> > following types at mysql_com.h that do not exist on MariaDB
> > mysql_com.h:
> >
> > MYSQL_TYPE_TIMESTAMP2,
> > MYSQL_TYPE_DATETIME2,
> > MYSQL_TYPE_TIME2,
>
> I do not know the details of this particular point (also yo
Hi.
Bumping this thread with a slightly different finding which may help
understanding the issue.
I'll use two command lines for this test, "MariaDB 1" and "MariaDB 2",
also distinguished by indentation level for readability.
Server version: 5.5.30-MariaDB-log MariaDB Server
Some setup:
Maria
On Tue, 21 May 2013 11:35:46 +0200,
Vincent Pelletier wrote :
> I'm surprised by delete's behaviour, as I am mentally applying
> to the btree the table is.
...to the btree the table (or index) is implemented with.
> Is it just a bad assumption from my part ?
Looks like I just found part of an a
Kristian,
There's a well-known problem in MySQL that relay_log.info is not
always in sync with the database state, and killing and restarting
server at an unfortunate time will cause it to re-execute last
statement and potentially break replication. Did you fix this
situation with GTIDs and rpl_sl
Hi!
> "Vincent" == Vincent Pelletier writes:
Vincent> Hi.
Vincent> Bumping this thread with a slightly different finding which may help
Vincent> understanding the issue.
Vincent> I'll use two command lines for this test, "MariaDB 1" and "MariaDB 2",
Vincent> also distinguished by indentati
On Tue, 21 May 2013 19:45:02 +0300,
Michael Widenius wrote :
> This is an optimization that Heikki did a long time ago that has this
> strange side effect.
>
> See the comment posted by Radek on
> http://dev.mysql.com/doc/refman/5.5/en/delete.html
I found that a bit after posting, yes...
Is ther
Pavel Ivanov writes:
> There's a well-known problem in MySQL that relay_log.info is not
> always in sync with the database state, and killing and restarting
> server at an unfortunate time will cause it to re-execute last
> statement and potentially break replication. Did you fix this
> situation
I'm glad to hear that. :)
On Tue, May 21, 2013 at 2:31 PM, Kristian Nielsen
wrote:
> There is currently a bug when restarting the *master* while the slave is still
> scanning for the GTID start position, but this will be fixed before GA of
> course.
Could you please elaborate what kind of bug is
Hi guys, i was looking git and i don't know if there's something similar to
mariadb alter table command
could we develop something like git for create database,alter tables,
create table, drop table, drop database?
a log that could be useful to update databases table definition and read
changes do
Pavel Ivanov writes:
> Could you please elaborate what kind of bug is that?
The slave connects to master with GTID. The binlog dump thread on the master
starts scanning the last binlog file to find the start position. It finds the
position for one replication domain, but aother domain is still s
Thank you for the explanation.
Pavel
On Tue, May 21, 2013 at 10:54 PM, Kristian Nielsen
wrote:
> Pavel Ivanov writes:
>
>> Could you please elaborate what kind of bug is that?
>
> The slave connects to master with GTID. The binlog dump thread on the master
> starts scanning the last binlog file
11 matches
Mail list logo
