- developers - lists.mariadb.org

Re: [Maria-developers] what pros/cons of storing binary log in an InnoDB table?
by Kristian Nielsen 31 Jan '13

31 Jan '13

Zardosht Kasheff <zardosht(a)gmail.com> writes: > Instead of having the binary log be stored as a log file, a table with > a transactional engine (like InnoDB) is used. I have NOT done any Yes, this is a tempting idea, is it not? Drizzle even implemented this. But there are some subtle problems, and I think there are better solutions. One problem you will find if you try implementing this is - how are you going to keep the concept of binlog order? A relational table is unordered. You can use an increasing uint64 as the primary key, but then how are you going to ensure that the order in the table is the same as the commit order in InnoDB (InnoDB redo log)? If you take a lock from allocating the sequence number to doing the commit, then you have introduced a serialisation bottleneck and killed group commit. If you accept different order (as Drizzle does), then when you take an XtraBackup, it may not be consistent with the binlog. You will be writing your data *6* times: To the real table, when flushing its buffer pool pages. To the double-write buffer while flushing, and to the redo log before flushing. Then to the binlog table, and before that to the redo log and the doublewrite buffer. I could never reconcile myself with this. So it is tempting, but re-implementing binlog is a huge change (also in terms of end-user visibility), and my personal opinion is that for such huge a change we need to go to the best solution, not second-best. > investigation into whether this is possible, but I'm wondering what > people abstractly think of this idea. > My major motivation is to find a way to have users not be forced to > fsync on every transaction commit on slaves. With crash safety of My preference is MWL#164: http://askmonty.org/worklog/Server-RawIdeaBin/?tid=164 This reduces to one fsync() per group commit. But as you point out, this is still horrendously expensive for a single-threaded slave :-( Abstractly, the proper solution is to store the binlog and the InnoDB redo log (and all other transactional-type logs) in the *same* log. The upper layer would provide a general transactional log facility, and binlog, InnoDB, partitioning, etc. would use this instead of their own logs. But it is hard to see how we could arrive there from current code ... For MariaDB global transaction ID, I support crash-safe without binlog enabled, so there turning off fsync() will be possible. But this does not help if a slave also needs to act as a master. Parallel replication can help a lot, by allowing group commit, amortising the cost of the fsync(). But it would still be nice to solve the orginal problem. As you say, for a slave it is not a problem to loose transactions in a crash as they can be just replicated again. The problem is to be consistent between what is in the InnoDB tables and what is in the binlog. InnoDB already records in a crash-safe way the binlog position of the last commit. So if we can ensure that InnoDB is never ahead of the binlog, we can just cut the binlog after a crash if it has more events than what InnoDB recovered. We could do this by doing binlog writes as async I/O O_DIRECT writes, and sending a signal somehow to InnoDB so it would buffer its own redo log until binlog is safe on disk. Then no fsync() would be needed. But this is so far just a loose idea, it needs more thought to be sure it can work... Anyway, this is my current long-term plan: if we cannot have a proper single database-wide transaction log, then instead coordinate writes between the multiple logs that exist. Delay writes to logs so that they are never ahead of the master log. And at crash, either recover missing pieces of logs from the master log (MWL#164), or cut logs to be consistent. Then we can be consistent without any fsync() delays. > - As I understand it, for two phase commit, storage engines are > currently expected to fsync once after a transaction is prepared and > once after a transaction is committed. If the binary log is an InnoDB > table, then two-phase commit is unnecessary and the number of fsyncs > on the system is cut in half. In MariaDB 10 and MySQL 5.6, the fsync() at commit is no longer needed (InnoDB does not have it). [Note that IIRC, MySQL 5.6 breaks the storage engine API, you will need to implement the skip-fsync-at-commit-stage, or you will loose group commit.] > - With crash safe slaves on MySQL 5.6, one theoretically does not > need to enable fsyncs on transaction commit on slaves. If some data > gets lost after a crash, then the data may be replayed from the > master. However, to get GTIDs working, one must enable the binary log > on slaves, which requires two-phase commit, which require fsyncs. By Yes, requiring binlog on slaves is a serious mistake :-( Ok, as you can perhaps tell, this is something I have thought a lot about over the past years, so I have a lot of ideas but it is a bit difficult to put it all in a single mail reply without it becomming mostly a jumble of loose ideas. You are welcome to ask for more details on any specific points of interest. - Kristian.

5 9

Re: [Maria-developers] reducing fsyncs during handlerton->prepare and handlerton->commit in 5.6
by Kristian Nielsen 31 Jan '13

31 Jan '13

Zardosht Kasheff <zardosht(a)gmail.com> writes: > - in MySQL 5.6 and MariaDB 10.0, what are the fsyncing requirements > for storage engines during prepare and commit? > - are there new APIs that the storage engine must comply with in > order to get these benefits? In MariaDB 10.0, there is a new commit_checkpoint_request handlerton method. If the storage engine implements that, it need not do the fsync() at commit. It must also implement the commit_ordered method from 5.3. Check comments in sql/handler.h for these two methods, and let me know if there are any questions. The intention is that storage engines need not do much extra work for this functionality, eg. the patch for InnoDB support was a couple hundred lines at most IIRC. > - in MySQL 5.6, I see new handlerton methods commit_low and > prepare_low. What do these APIs do? What is their contract? I think MySQL developers should answer for this. But it is related to this new check in InnoDB: thd_requested_durability(trx->mysql_thd) == HA_IGNORE_DURABILITY And the existing flush_logs handlerton method is also used. My guess is that commit_low is just internal server stuff that the storage engine does not need to consider. The MySQL 5.6 mechanism is mostly the same as the MariaDB 10.0 one in what it actually does, but they did not bother to try to be compatible with the storage engine API in MariaDB 5.3. So looks like it is #ifdef time for you if you want to support both. - Kristian.

1 0

[Maria-developers] how to build mariadb RPMs
by Rich Prohaska 30 Jan '13

30 Jan '13

How do you build the mariadb RPMs? Are you using rpmbuild or cpack? Is there a top level script that uses rpmbuild or cpack that I should use? Thanks Rich Prohaska

3 11

[Maria-developers] MariaDB 5.1.67, 5.2.14, 5.3.12, 5.5.29 Release Prep
by Daniel Bartholomew 29 Jan '13

29 Jan '13

All, I've prepped changelog and release notes pages for MariaDB 5.1.67, 5.2.14, and 5.3.12. I'll shortly be doing the same for MariaDB 5.5.29. https://kb.askmonty.org/en/mariadb-5167-release-notes/ https://kb.askmonty.org/en/mariadb-5167-changelog/ https://kb.askmonty.org/en/mariadb-5214-release-notes/ https://kb.askmonty.org/en/mariadb-5214-changelog/ https://kb.askmonty.org/en/mariadb-5312-release-notes/ https://kb.askmonty.org/en/mariadb-5312-changelog/ If there is anything I should be sure to mention in the release notes, please let me know ASAP. I plan on announcing the releases once 5.5.29 has been uploaded to the mirrors. It's still building at the moment so the earliest the release could happen is tomorrow and it could be pushed back to Thursday if there's a delay of some sort. Thanks. -- Daniel Bartholomew Google+ - http://gplus.to/dbart Twitter - http://twitter.com/daniel_bart MariaDB: An Enhanced Drop-in Replacement for MySQL Website - http://mariadb.org Twitter - http://twitter.com/mariadb Google+ - http://google.com/+mariadb Facebook - http://fb.com/MariaDB.dbms Knowledgebase - http://kb.askmonty.org Monty Program - http://montyprogram.com

1 0

Re: [Maria-developers] [Commits] Rev 3653: MDEV-3882 .deb upgrade from mysql to mariadb fails due to apt-get considering it a downgrade. in file:///home/hf/wmar/mdev-3882/
by Kristian Nielsen 29 Jan '13

29 Jan '13

<holyfoot(a)askmonty.org> writes: > message: > MDEV-3882 .deb upgrade from mysql to mariadb fails due to apt-get considering it a downgrade. > The libmysqlclient18 package and all the dependencies on it removed. > The libmariadbclient18 set to provide the libmysqlclient's functions and > conflicts with all the libmysqlclients. > > === modified file 'debian/dist/Debian/control' > --- a/debian/dist/Debian/control 2012-08-23 13:32:03 +0000 > +++ b/debian/dist/Debian/control 2013-01-29 09:56:54 +0000 > @@ -13,7 +13,9 @@ Vcs-Bzr: bzr://lp:maria > Package: libmariadbclient18 > Section: libs > Architecture: any > -Depends: mariadb-common, libmysqlclient18 (= ${source:Version}), ${shlibs:Depends}, ${misc:Depends} > +Depends: mariadb-common, ${shlibs:Depends}, ${misc:Depends} > +Provides: libmysqlclient18 > +Conflicts: libmysqlclient10, libmysqlclient12, libmysqlclient14, libmysqlclient15, libmysqlclient16, libmysqlclient18 Are you sure this works? The original reason for introducing a libmysqlclient18 package in the first place (with all the problems in introduces) is that there are standard packages with a versioned dependency on libmysqlclient18. And versioned dependencies can not (used not to?) be satisfied by a Provides: Eg. the following gives 143 packages with versioned dependencies on libmysqlclient18: apt-cache rdepends libmysqlclient18|(read x; read x; while read x; do apt-cache show $x|grep ^Depends: | perl -nle 'print "'"$x:"' $1" if /libmysqlclient18[ \t]*$([^)]+)$/' ; done) You need to test a number of these that they are still installable when MariaDB is installed, also on old .deb distros (ie. Ubuntu 8.04). On the other hand, if this works then it is a nice solution for sure, and could also solve other issues. A related issue is that we might get the distro mysql-common package or the MariaDB mysql-common package somewhat at random, depending on which has the newer version number on any given day. I believe we made it so we work with the distro mysql-common package as well as the MariaDB one, it it will not necessarily cause any problems. It does seem a bit of a mess though, maybe we should just drop the mysql-common package from our repos? - Kristian.

1 0

Re: [Maria-developers] Fwd: [Commits] Rev 3616: Fix for bug in file:///home/tsk/mprog/src/5.3-md641/
by Igor Babaev 28 Jan '13

28 Jan '13

Timour, It's not clear for me: 1. why group by queries with GROUP BY col1, col2, where col1,col2 are defined over the same table, are considered as possibly good for for loose scan optimization. 2. how it comes that unique index is considered as a candidate for a loose scan (see your test case). (The second issue, of course, are unrelated to bug mdev-641). Besides, didn't you notice that you removes duplicates in group by under any circumstances. How it will affect the following query: select a, sum(c) from t1 group by a, a with rollup; ? In general, removing duplicates from GROUP BY and ORDER BY lists is a good optimization, but why it should be done in connection with this bug? Regards, Igor. On 01/24/2013 06:38 AM, Timour Katchaounov wrote: > Igor, > > Could you please review the following patch (we discussed it at the team > call): > > ------------------------------------------------------------ > revno: 3616 > revision-id: timour(a)askmonty.org-20130124143526-bpaiyushble1ieek > parent: timour(a)askmonty.org-20130117140805-4kyoq7azx4v2irhq > fixes bug: https://mariadb.atlassian.net/browse/MDEV-614 > committer: timour(a)askmonty.org > branch nick: 5.3-md641 > timestamp: Thu 2013-01-24 16:35:26 +0200 > message: > Fix for bug > MDEV-641 LP:1002108 - Wrong result (or crash) from a query with > duplicated field in the group list and a limit clause > Bug#11761078: 53534: INCORRECT 'SELECT SQL_BIG_RESULT...' > WITH GROUP BY ON DUPLICATED FIELDS > > Analysis > Range analysis discoveres that the query can be executed via loose > index scan for GROUP BY. > Later, GROUP BY analysis fails to confirm that the GROUP operation can > be computed via an > index because there is no logic to handle duplicate field references > in the GROUP clause. > As a result the optimizer the optimizer produces an inconsistent plan. > It constructs a > temporary table, but on the other hand the group fields are not set to > point there. > > Solution: > Make order by analysis be in sync with loose scan analysis for group > by. Instead of > changing the logic of how indexes are analyzed for order by, the patch > takes the same > approach as MySQL - normalize the query by removing duplicate column > references. The > difference from MySQL is that we remove duplicates earlier, by reusing > remove_const() > which already removed unneeded ORDER elements. > >

1 0

[Maria-developers] MDEV-3875 Wrong result on a DISTINCT query ... and GROUP BY
by Sergei Golubchik 27 Jan '13

27 Jan '13

Hi, Igor, See my patch below. The only questionable part - in remove_dup_with_compare(). Before it was memcpy'ing only part of the record, skipping const fields. Now it memcpy's the complete record. I don't think it matters much performance-wise. An alternative would be to do two memcpy's - for the NULL bitmap and for the fields (because const fields are located between the NULL bitmap that we need, and the other non-const fields). Another alternative would be to have const fields at the end of the record, but it'd be a much larger and more risky change. ------------------------------------------------------------ revno: 3620 fixes bug: https://mariadb.atlassian.net/browse/MDEV-3875 committer: Sergei Golubchik <sergii(a)pisem.net> branch nick: 5.3 timestamp: Sat 2013-01-26 22:33:18 +0100 message: MDEV-3875 Wrong result (missing row) on a DISTINCT query with the same subquery in the SELECT list and GROUP BY fix remove_dup_with_hash_index() and remove_dup_with_compare() to take NULLs into account modified: mysql-test/r/distinct.result mysql-test/t/distinct.test sql/field.cc sql/field.h sql/filesort.cc sql/sql_select.cc diff: === modified file 'mysql-test/r/distinct.result' --- mysql-test/r/distinct.result 2011-12-15 22:26:59 +0000 +++ mysql-test/r/distinct.result 2013-01-26 21:33:18 +0000 @@ -847,3 +847,35 @@ time(f1) 00:00:00.000200 00:00:00.000300 drop table t1; +create table t1(i int, g int); +insert into t1 values (null, 1), (0, 2); +select distinct i from t1 group by g; +i +NULL +0 +drop table t1; +create table t1(i int, g blob); +insert into t1 values (null, 1), (0, 2); +select distinct i from t1 group by g; +i +NULL +0 +drop table t1; +create table t1 (a int) engine=myisam; +insert into t1 values (0),(7); +create table t2 (b int) engine=myisam; +insert into t2 values (7),(0),(3); +create algorithm=temptable view v as +select distinct (select max(a) from t1 where alias.b = a) as field1 from t2 as alias group by field1; +select * from v; +field1 +NULL +0 +7 +select distinct (select max(a) from t1 where alias.b = a) as field1 from t2 as alias group by field1; +field1 +NULL +0 +7 +drop view v; +drop table t1, t2; === modified file 'mysql-test/t/distinct.test' --- mysql-test/t/distinct.test 2011-12-15 22:26:59 +0000 +++ mysql-test/t/distinct.test 2013-01-26 21:33:18 +0000 @@ -658,3 +658,27 @@ select time(f1) from t1 ; select distinct time(f1) from t1 ; drop table t1; +# +# MDEV-3875 Wrong result (missing row) on a DISTINCT query with the same subquery in the SELECT list and GROUP BY +# MySQL Bug#66896 Distinct not distinguishing 0 from NULL when GROUP BY is used +# +create table t1(i int, g int); # remove_dup_with_hash_index +insert into t1 values (null, 1), (0, 2); +select distinct i from t1 group by g; +drop table t1; + +create table t1(i int, g blob); # remove_dup_with_compare +insert into t1 values (null, 1), (0, 2); +select distinct i from t1 group by g; +drop table t1; + +create table t1 (a int) engine=myisam; +insert into t1 values (0),(7); +create table t2 (b int) engine=myisam; +insert into t2 values (7),(0),(3); +create algorithm=temptable view v as +select distinct (select max(a) from t1 where alias.b = a) as field1 from t2 as alias group by field1; +select * from v; +select distinct (select max(a) from t1 where alias.b = a) as field1 from t2 as alias group by field1; +drop view v; +drop table t1, t2; === modified file 'sql/field.cc' --- sql/field.cc 2012-08-29 15:55:59 +0000 +++ sql/field.cc 2013-01-26 21:33:18 +0000 @@ -1062,6 +1062,21 @@ bool Field::type_can_have_key_part(enum } +void Field::make_sort_key(uchar *buff,uint length) +{ + if (maybe_null()) + { + if (is_null()) + { + bzero(buff, length + 1); + return; + } + *buff++= 1; + } + sort_string(buff, length); +} + + /** Numeric fields base class constructor. */ === modified file 'sql/field.h' --- sql/field.h 2012-06-23 22:00:05 +0000 +++ sql/field.h 2013-01-26 21:33:18 +0000 @@ -386,6 +386,7 @@ class Field return bytes; } + void make_sort_key(uchar *buff, uint length); virtual void make_field(Send_field *); virtual void sort_string(uchar *buff,uint length)=0; virtual bool optimize_range(uint idx, uint part); === modified file 'sql/filesort.cc' --- sql/filesort.cc 2012-11-09 08:11:20 +0000 +++ sql/filesort.cc 2013-01-26 21:33:18 +0000 @@ -783,21 +783,9 @@ static void make_sortkey(register SORTPA bool maybe_null=0; if ((field=sort_field->field)) { // Field - if (field->maybe_null()) - { - if (field->is_null()) - { - if (sort_field->reverse) - bfill(to,sort_field->length+1,(char) 255); - else - bzero((char*) to,sort_field->length+1); - to+= sort_field->length+1; - continue; - } - else - *to++=1; - } - field->sort_string(to, sort_field->length); + field->make_sort_key(to, sort_field->length); + if ((maybe_null = field->maybe_null())) + to++; } else { // Item @@ -949,8 +937,11 @@ static void make_sortkey(register SORTPA } if (sort_field->reverse) { /* Revers key */ - if (maybe_null) - to[-1]= ~to[-1]; + if (maybe_null && (to[-1]= !to[-1])) + { + to+= sort_field->length; // don't waste the time reversing all 0's + continue; + } length=sort_field->length; while (length--) { === modified file 'sql/sql_select.cc' --- sql/sql_select.cc 2013-01-16 13:11:13 +0000 +++ sql/sql_select.cc 2013-01-26 21:33:18 +0000 @@ -204,7 +204,7 @@ static int create_sort_index(THD *thd, J static int remove_duplicates(JOIN *join,TABLE *entry,List<Item> &fields, Item *having); static int remove_dup_with_compare(THD *thd, TABLE *entry, Field **field, - ulong offset,Item *having); + Item *having); static int remove_dup_with_hash_index(THD *thd,TABLE *table, uint field_count, Field **first_field, ulong key_length,Item *having); @@ -18891,19 +18891,24 @@ static bool fix_having(JOIN *join, Item #endif -/***************************************************************************** - Remove duplicates from tmp table - This should be recoded to add a unique index to the table and remove - duplicates - Table is a locked single thread table - fields is the number of fields to check (from the end) -*****************************************************************************/ +/** + Compare fields from table->record[0] and table->record[1], + possibly skipping few first fields. + @param table + @param ptr field to start the comparison from, + somewhere in the table->field[] array + + @retval 1 different + @retval 0 identical +*/ static bool compare_record(TABLE *table, Field **ptr) { for (; *ptr ; ptr++) { - if ((*ptr)->cmp_offset(table->s->rec_buff_length)) + Field *f= *ptr; + if (f->is_null() != f->is_null(table->s->rec_buff_length) || + (!f->is_null() && f->cmp_offset(table->s->rec_buff_length))) return 1; } return 0; @@ -18931,15 +18936,15 @@ static void free_blobs(Field **ptr) static int -remove_duplicates(JOIN *join, TABLE *entry,List<Item> &fields, Item *having) +remove_duplicates(JOIN *join, TABLE *table, List<Item> &fields, Item *having) { int error; - ulong reclength,offset; + ulong keylength= 0; uint field_count; THD *thd= join->thd; DBUG_ENTER("remove_duplicates"); - entry->reginfo.lock_type=TL_WRITE; + table->reginfo.lock_type=TL_WRITE; /* Calculate how many saved fields there is in list */ field_count=0; @@ -18956,24 +18961,21 @@ remove_duplicates(JOIN *join, TABLE *ent join->unit->select_limit_cnt= 1; // Only send first row DBUG_RETURN(0); } - Field **first_field=entry->field+entry->s->fields - field_count; - offset= (field_count ? - entry->field[entry->s->fields - field_count]-> - offset(entry->record[0]) : 0); - reclength=entry->s->reclength-offset; - - free_io_cache(entry); // Safety - entry->file->info(HA_STATUS_VARIABLE); - if (entry->s->db_type() == heap_hton || - (!entry->s->blob_fields && - ((ALIGN_SIZE(reclength) + HASH_OVERHEAD) * entry->file->stats.records < + + Field **first_field=table->field+table->s->fields - field_count; + for (Field **ptr=first_field; *ptr; ptr++) + keylength+= (*ptr)->sort_length() + (*ptr)->maybe_null(); + + free_io_cache(table); // Safety + table->file->info(HA_STATUS_VARIABLE); + if (table->s->db_type() == heap_hton || + (!table->s->blob_fields && + ((ALIGN_SIZE(keylength) + HASH_OVERHEAD) * table->file->stats.records < thd->variables.sortbuff_size))) - error=remove_dup_with_hash_index(join->thd, entry, - field_count, first_field, - reclength, having); + error=remove_dup_with_hash_index(join->thd, table, field_count, first_field, + keylength, having); else - error=remove_dup_with_compare(join->thd, entry, first_field, offset, - having); + error=remove_dup_with_compare(join->thd, table, first_field, having); free_blobs(first_field); DBUG_RETURN(error); @@ -18981,18 +18983,13 @@ remove_duplicates(JOIN *join, TABLE *ent static int remove_dup_with_compare(THD *thd, TABLE *table, Field **first_field, - ulong offset, Item *having) + Item *having) { handler *file=table->file; - char *org_record,*new_record; - uchar *record; + uchar *record=table->record[0]; int error; - ulong reclength= table->s->reclength-offset; DBUG_ENTER("remove_dup_with_compare"); - org_record=(char*) (record=table->record[0])+offset; - new_record=(char*) table->record[1]+offset; - if (file->ha_rnd_init_with_error(1)) DBUG_RETURN(1); @@ -19029,7 +19026,7 @@ static int remove_dup_with_compare(THD * error=0; goto err; } - memcpy(new_record,org_record,reclength); + store_record(table,record[1]); /* Read through rest of file and mark duplicated rows deleted */ bool found=0; @@ -19088,8 +19085,9 @@ static int remove_dup_with_hash_index(TH int error; handler *file= table->file; ulong extra_length= ALIGN_SIZE(key_length)-key_length; - uint *field_lengths,*field_length; + uint *field_lengths, *field_length; HASH hash; + Field **ptr; DBUG_ENTER("remove_dup_with_hash_index"); if (!my_multi_malloc(MYF(MY_WME), @@ -19101,21 +19099,8 @@ static int remove_dup_with_hash_index(TH NullS)) DBUG_RETURN(1); - { - Field **ptr; - ulong total_length= 0; - for (ptr= first_field, field_length=field_lengths ; *ptr ; ptr++) - { - uint length= (*ptr)->sort_length(); - (*field_length++)= length; - total_length+= length; - } - DBUG_PRINT("info",("field_count: %u key_length: %lu total_length: %lu", - field_count, key_length, total_length)); - DBUG_ASSERT(total_length <= key_length); - key_length= total_length; - extra_length= ALIGN_SIZE(key_length)-key_length; - } + for (ptr= first_field, field_length=field_lengths ; *ptr ; ptr++) + (*field_length++)= (*ptr)->sort_length(); if (hash_init(&hash, &my_charset_bin, (uint) file->stats.records, 0, key_length, (hash_get_key) 0, 0, 0)) @@ -19155,13 +19140,13 @@ static int remove_dup_with_hash_index(TH /* copy fields to key buffer */ org_key_pos= key_pos; field_length=field_lengths; - for (Field **ptr= first_field ; *ptr ; ptr++) + for (ptr= first_field ; *ptr ; ptr++) { - (*ptr)->sort_string(key_pos,*field_length); - key_pos+= *field_length++; + (*ptr)->make_sort_key(key_pos, *field_length); + key_pos+= (*ptr)->maybe_null() + *field_length++; } /* Check if it exists before */ - if (hash_search(&hash, org_key_pos, key_length)) + if (my_hash_search(&hash, org_key_pos, key_length)) { /* Duplicated found ; Remove the row */ if ((error= file->ha_delete_row(record))) Regards, Sergei

1 0

[Maria-developers] MariaDB RPMs
by Rich Prohaska 24 Jan '13

24 Jan '13

Suppose that we have a RHEL5 machine running and we want to install MariaDB on it. Unfortunately, it conflicts with files installed by the mysql package. # rpm -i MariaDB-5.5.28a-centos5-x86_64-common.rpm warning: MariaDB-5.5.28a-centos5-x86_64-common.rpm: Header V3 DSA signature: NOKEY, key ID 1bb943db file /etc/my.cnf from install of MariaDB-common-5.5.28a-1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.x86_64 file /usr/share/mysql/charsets/Index.xml from install of MariaDB-common-5.5.28a-1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.x86_64 file /usr/share/mysql/charsets/cp1250.xml from install of MariaDB-common-5.5.28a-1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.x86_64 file /usr/share/mysql/charsets/cp1251.xml from install of MariaDB-common-5.5.28a-1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.x86_64 Unfortunately, a lot of other packages require the mysql package. What is a good approach to solving this problem? Thanks

2 1

[Maria-developers] A new Ubuntu UPDATE event problem smashed MariaDB dead
by Peter W Bowey 23 Jan '13

23 Jan '13

Subject: A new Ubuntu UPDATE event problem smashed MariaDB 5.5.28a dead Hi MariaDB Team, Ubuntu released a update 23 hours ago that 'smashed out' omega8.cc's careful work to support MariaDB 5.5.28-mariadb-a1~precise. Ubuntu's new version is '5.5.29-0ubuntu012.10.1' dated - 2013-01-22 15:07:08 UTC. This does not work yet with MariaDB & Ubuntu 12.04 See Link here: https://launchpad.net/ubuntu/quantal/+source/mysql-5.5/5.5.29-0ubuntu0.12..… Now, I have been 'battling for hours' to work around this Ubuntu pain, while we wait on the good MariaDB team to re-syncs it's own updates with the Ubuntu 12.04 updates. Here is the 'crude *forced* style' I worked with to MariaDB back to life - after the Ubuntu *forced* update and dependency killed the database [MariaDB]: -------------------------------------------------------------------------------- server:~/aegir-boa-installer# aptitude install mariadb-server-5.5 mariadb-common The following NEW packages will be installed: libdbd-mysql-perl{a} libmariadbclient18{ab} libmysqlclient18{a} mariadb-client-5.5{a} mariadb-client-core-5.5{a} mariadb-server-5.5 mariadb-server-core-5.5{a} 0 packages upgraded, 7 newly installed, 0 to remove and 0 not upgraded. Need to get 31.8 MB of archives. After unpacking 107 MB will be used. The following packages have unmet dependencies: mysql-common : Breaks: mysql-client-5.1 which is a virtual package. Breaks: mysql-client-core-5.1 which is a virtual package. Breaks: mysql-server-core-5.1 which is a virtual package. libmariadbclient18 : Depends: libmysqlclient18 (= 5.5.28-mariadb-a1~precise) but 5.5.29-0ubuntu0.12.04.1 is to be installed. The following actions will resolve these dependencies: Keep the following packages at their current version: 1) libmariadbclient18 [Not Installed] 2) mariadb-client-5.5 [Not Installed] 3) mariadb-client-core-5.5 [Not Installed] 4) mariadb-server-5.5 [Not Installed] 5) mariadb-server-core-5.5 [Not Installed] Accept this solution? [Y/n/q/?] n The following actions will resolve these dependencies: Install the following packages: 1) libmysqlclient18 [5.5.28-mariadb-a1~precise (<NULL>)] Downgrade the following packages: 2) mysql-common [5.5.29-0ubuntu0.12.04.1 (now, precise-security, precise-updates) -> 5.5.28-mariadb-a1~precise (<NULL>)] Accept this solution? [Y/n/q/?] The following packages will be DOWNGRADED: mysql-common The following NEW packages will be installed: libdbd-mysql-perl{a} libmariadbclient18{a} libmysqlclient18{a} mariadb-client-5.5{a} mariadb-client-core-5.5{a} mariadb-server-5.5 mariadb-server-core-5.5{a} 0 packages upgraded, 7 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 30.9 MB of archives. After unpacking 104 MB will be used. Do you want to continue? [Y/n/?] y Get: 1 http://archive.ubuntu.com/ubuntu/ precise/main libdbd-mysql-perl i386 4.020-1build2 [104 kB] Get: 2 http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/ precise/main mysql-common all 5.5.28-mariadb-a1~precise [8,780 B] Get: 3 http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/ precise/main libmariadbclient18 i386 5.5.28-mariadb-a1~precise [817 kB] Get: 4 http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/ precise/main libmysqlclient18 i386 5.5.28-mariadb-a1~precise [2,920 B] Get: 5 http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/ precise/main mariadb-client-core-5.5 i386 5.5.28-mariadb-a1~precise [1,797 kB] Get: 6 http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/ precise/main mariadb-client-5.5 i386 5.5.28-mariadb-a1~precise [5,097 kB] Get: 7 http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/ precise/main mariadb-server-core-5.5 i386 5.5.28-mariadb-a1~precise [5,113 kB] Get: 8 http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/ precise/main mariadb-server-5.5 i386 5.5.28-mariadb-a1~precise [18.0 MB] Fetched 30.9 MB in 30s (1,020 kB/s) Preconfiguring packages ... dpkg: warning: downgrading mysql-common from 5.5.29-0ubuntu0.12.04.1 to 5.528-mariadb-a1~precise. (Reading database ... 61332 files and directories currently installed.) Preparing to replace mysql-common 5.5.29-0ubuntu0.12.04.1 (using ..../mysql-common_5.5.28-mariadb-a1~precise_all.deb) ... Unpacking replacement mysql-common ... Selecting previously unselected package libmariadbclient18. Unpacking libmariadbclient18 (from ..../libmariadbclient18_5.5.28-mariadb-a1~precise_i386.deb) ... Selecting previously unselected package libmysqlclient18. Unpacking libmysqlclient18 (from ..../libmysqlclient18_5.5.28-mariadb-a1~precise_i386.deb) ... Selecting previously unselected package libdbd-mysql-perl. Unpacking libdbd-mysql-perl (from ..../libdbd-mysql-perl_4.020-1build2_i386deb) ... Selecting previously unselected package mariadb-client-core-5.5. Unpacking mariadb-client-core-5.5 (from ..../mariadb-client-core-5.5_5.5.28-mariadb-a1~precise_i386.deb) ... Selecting previously unselected package mariadb-client-5.5. Unpacking mariadb-client-5.5 (from ..../mariadb-client-5.5_5.5.28-mariadb-a1~precise_i386.deb) ... Selecting previously unselected package mariadb-server-core-5.5. Unpacking mariadb-server-core-5.5 (from ..../mariadb-server-core-5.5_5.5.28-mariadb-a1~precise_i386.deb) ... Selecting previously unselected package mariadb-server-5.5. Unpacking mariadb-server-5.5 (from ..../mariadb-server-5.5_5.5.28-mariadb-a1~precise_i386.deb) ... * Stopping MariaDB database server mysqld [ OK ] Processing triggers for man-db ... Processing triggers for ureadahead ... Setting up mysql-common (5.5.28-mariadb-a1~precise) ... Configuration file `/etc/mysql/my.cnf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** my.cnf (Y/I/N/O/D/Z) [default=N] ? N Setting up libmysqlclient18 (5.5.28-mariadb-a1~precise) ... Setting up libdbd-mysql-perl (4.020-1build2) ... Setting up libmariadbclient18 (5.5.28-mariadb-a1~precise) ... Setting up mariadb-client-core-5.5 (5.5.28-mariadb-a1~precise) ... Setting up mariadb-client-5.5 (5.5.28-mariadb-a1~precise) ... Setting up mariadb-server-core-5.5 (5.5.28-mariadb-a1~precise) ... Setting up mariadb-server-5.5 (5.5.28-mariadb-a1~precise) ... * Stopping MariaDB database server mysqld [ OK ] * Starting MariaDB database server mysqld [ OK ] * Checking for corrupt, not cleanly closed and upgrade needing tables. Processing triggers for libc-bin ... ldconfig deferred processing now taking place -------------------------------------------------------------------------------- Ubuntu will drag in the new update dependants - > mysql-common [5.5.29-0ubuntu0.12.04.1 (now, precise-security, precise-updates) instead of 5.5.28-mariadb-a1~precise (<NULL>)] Peter Peter Bowey Web Design & Developer Peter Bowey Computer Solutions 69 Sutherland Ave, Victor Harbor, South Australia, Australia Tel.: 08 8552 8630 Fax: 08 8552 9185 Email: support(a)pbcomp.com.au Web: http://www.pbcomp.com.au/ Making Windows, Macintosh & Linux work for you! http://www.pbcomp.com.au/ This email and any attachment is intended only for the exclusive and confidential use of the addressee(s). If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify the sender by return email immediately and delete the message from your computer without making any copies and publishing the contents therein. Consider the environment before printing this e-mail.

2 1

Re: [Maria-developers] Rev 3177: Fixed bug mdev-4063 (bug #56927)
by Sergei Golubchik 21 Jan '13

21 Jan '13

Hi, Igor! On Jan 21, Igor Babaev wrote: > revno: 3177 > revision-id: igor(a)askmonty.org-20130121084657-hvcval7hykojxpmg > parent: sergii(a)pisem.net-20130109225151-z9e7gh8z5nl38dxl > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-5.1-bug56927 > timestamp: Mon 2013-01-21 00:46:57 -0800 > message: > Fixed bug mdev-4063 (bug #56927). > This bug could result in returning 0 for the expressions of the form > <aggregate_function>(distinct field) when the system variable > max_heap_table_size was set to a small enough number. > It happened because the method Unique::walk() did not support > the case when more than one pass was needed to merge the trees > of distinct values saved in an external file. Looks ok. Just one thought. You use merge_many_buff() if the memory is not enough for the number_of_buffpeks*size. But merge_many_buff() only reduces the number of buffpeks down to 15. What if max_heap_table_size < 15*size ? I'd suggest to either 1) issue an error or 2) merge completely, like in Unique::get(). Actually, 2) should be easy, you just pass the last argument to your new Unique::merge() instead of TRUE, like in your patch, change to merge( ..., max_in_memory_size > MERGEBUFF2*size); Regards, Sergei

1 0