<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/mariadb-git.git/sql, branch bb-10.3-cpp11</title>
<subtitle>github.com: MariaDB/server.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/'/>
<entry>
<title>One more compilation error fix for c++11 in runtime code</title>
<updated>2019-04-27T01:59:53+00:00</updated>
<author>
<name>Vlad Lesin</name>
<email>vlad_lesin@mail.ru</email>
</author>
<published>2019-04-25T20:36:42+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=e9b3bfa18c8e680a69fdb2f83d9ba46a91ab398e'/>
<id>e9b3bfa18c8e680a69fdb2f83d9ba46a91ab398e</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Compilation error fix</title>
<updated>2019-04-26T11:10:58+00:00</updated>
<author>
<name>Vlad Lesin</name>
<email>vlad_lesin@mail.ru</email>
</author>
<published>2019-04-25T04:43:14+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=5fd42a7469be8f6e8498342abd11976d497d51d0'/>
<id>5fd42a7469be8f6e8498342abd11976d497d51d0</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge 10.2 into 10.3</title>
<updated>2019-04-25T06:05:52+00:00</updated>
<author>
<name>Marko Mäkelä</name>
<email>marko.makela@mariadb.com</email>
</author>
<published>2019-04-25T06:05:52+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=acf6f92aa936fbfe7524617ae57d011ab8f1f96d'/>
<id>acf6f92aa936fbfe7524617ae57d011ab8f1f96d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge 10.1 into 10.2</title>
<updated>2019-04-25T06:04:09+00:00</updated>
<author>
<name>Marko Mäkelä</name>
<email>marko.makela@mariadb.com</email>
</author>
<published>2019-04-25T06:04:09+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=bc145193c164b895a52b943e73fff53952d48a60'/>
<id>bc145193c164b895a52b943e73fff53952d48a60</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge 5.5 into 10.1</title>
<updated>2019-04-24T09:03:11+00:00</updated>
<author>
<name>Marko Mäkelä</name>
<email>marko.makela@mariadb.com</email>
</author>
<published>2019-04-24T09:03:11+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=bfb0726fc24acb896e54bc7ef7536ad1aab9d574'/>
<id>bfb0726fc24acb896e54bc7ef7536ad1aab9d574</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>MDEV-15772 Potential list overrun during XA recovery</title>
<updated>2019-04-24T08:46:14+00:00</updated>
<author>
<name>Thirunarayanan Balathandayuthapani</name>
<email>thiru@mariadb.com</email>
</author>
<published>2019-04-24T07:01:24+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=d5da8ae04d57556f517c0f03afeafe73c6cc75d1'/>
<id>d5da8ae04d57556f517c0f03afeafe73c6cc75d1</id>
<content type='text'>
InnoDB could return the same list again and again if the buffer
passed to trx_recover_for_mysql() is smaller than the number of
transactions that InnoDB recovered in XA PREPARE state.

We introduce the transaction state TRX_PREPARED_RECOVERED, which
is like TRX_PREPARED, but will be set during trx_recover_for_mysql()
so that each transaction will only be returned once.

Because init_server_components() is invoking ha_recover() twice,
we must reset the state of the transactions back to TRX_PREPARED
after returning the complete list, so that repeated traversals
will see the complete list again, instead of seeing an empty list.
Without this tweak, the test main.tc_heuristic_recover would hang
in MariaDB 10.1.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
InnoDB could return the same list again and again if the buffer
passed to trx_recover_for_mysql() is smaller than the number of
transactions that InnoDB recovered in XA PREPARE state.

We introduce the transaction state TRX_PREPARED_RECOVERED, which
is like TRX_PREPARED, but will be set during trx_recover_for_mysql()
so that each transaction will only be returned once.

Because init_server_components() is invoking ha_recover() twice,
we must reset the state of the transactions back to TRX_PREPARED
after returning the complete list, so that repeated traversals
will see the complete list again, instead of seeing an empty list.
Without this tweak, the test main.tc_heuristic_recover would hang
in MariaDB 10.1.
</pre>
</div>
</content>
</entry>
<entry>
<title>MDEV-15837: Assertion `item1-&gt;type() == Item::FIELD_ITEM &amp;&amp; item2-&gt;type() == Item::FIELD_ITEM'</title>
<updated>2019-04-24T07:28:04+00:00</updated>
<author>
<name>Varun Gupta</name>
<email>varun.gupta@mariadb.com</email>
</author>
<published>2019-04-23T18:46:56+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=1f1a61cfc41a01ffa65d568eebdc037a54b5c463'/>
<id>1f1a61cfc41a01ffa65d568eebdc037a54b5c463</id>
<content type='text'>
            failed in compare_order_elements function

The issue here is the function compare_order_lists() is called for the order by list of the window functions
so that those window function that can be computed together are adjacent.
So in the function compare_order_list we iterate over all the elements in the order list of the two functions and
compare the items in their order by clause.
The function compare_order_elements() is called for each item in the
order by clause. This function assumes that all the items that are in the order by list would be of the type
Item::FIELD_ITEM.

The case we have is that we have constants in the order by clause. We should ignore the constant and only compare
items of the type Item::FIELD_ITEM in compare_order_elements()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
            failed in compare_order_elements function

The issue here is the function compare_order_lists() is called for the order by list of the window functions
so that those window function that can be computed together are adjacent.
So in the function compare_order_list we iterate over all the elements in the order list of the two functions and
compare the items in their order by clause.
The function compare_order_elements() is called for each item in the
order by clause. This function assumes that all the items that are in the order by list would be of the type
Item::FIELD_ITEM.

The case we have is that we have constants in the order by clause. We should ignore the constant and only compare
items of the type Item::FIELD_ITEM in compare_order_elements()
</pre>
</div>
</content>
</entry>
<entry>
<title>MDEV-17796 WHERE filter is ignored by DISTINCT IFNULL(GROUP_CONCAT(X), Y)</title>
<updated>2019-04-24T06:10:46+00:00</updated>
<author>
<name>Igor Babaev</name>
<email>igor@askmonty.org</email>
</author>
<published>2019-04-24T06:10:46+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=5fc8dd8b82e995b3c685f4e71700201097431358'/>
<id>5fc8dd8b82e995b3c685f4e71700201097431358</id>
<content type='text'>
           with GROUP BY + ORDER BY

The method JOIN::create_postjoin_aggr_table() should not call
call JOIN::add_sorting_to_table() unless the first non-constant join
table is passed as the first parameter to the method.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
           with GROUP BY + ORDER BY

The method JOIN::create_postjoin_aggr_table() should not call
call JOIN::add_sorting_to_table() unless the first non-constant join
table is passed as the first parameter to the method.
</pre>
</div>
</content>
</entry>
<entry>
<title>MDEV-9465 The constructor StringBuffer(const char *str, size_t length, const CHARSET_INFO *cs) looks suspicious</title>
<updated>2019-04-23T05:11:42+00:00</updated>
<author>
<name>Alexander Barkov</name>
<email>bar@mariadb.com</email>
</author>
<published>2019-04-23T05:11:42+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=9dcfd6be94bd83d14fd48d69ce487eb0ea3fe37f'/>
<id>9dcfd6be94bd83d14fd48d69ce487eb0ea3fe37f</id>
<content type='text'>
Removing the suspicious constructor, it's not used in the code anyway.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Removing the suspicious constructor, it's not used in the code anyway.
</pre>
</div>
</content>
</entry>
<entry>
<title>MDEV-17605 Statistics for InnoDB table is wrong if persistent statistics is used</title>
<updated>2019-04-23T00:11:07+00:00</updated>
<author>
<name>Igor Babaev</name>
<email>igor@askmonty.org</email>
</author>
<published>2019-04-23T00:10:42+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/mariadb-git.git/commit/?id=279a907fd0dea30be6d11fc4a5d63b1b98d0b329'/>
<id>279a907fd0dea30be6d11fc4a5d63b1b98d0b329</id>
<content type='text'>
The command SHOW INDEXES ignored setting of the system variable
use_stat_tables to the value of 'preferably' and and showed statistical
data received from the engine. Similarly queries over the table
STATISTICS from INFORMATION_SCHEMA ignored this setting. It happened
because the function fill_schema_table_by_open() did not read any data
from statistical tables.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The command SHOW INDEXES ignored setting of the system variable
use_stat_tables to the value of 'preferably' and and showed statistical
data received from the engine. Similarly queries over the table
STATISTICS from INFORMATION_SCHEMA ignored this setting. It happened
because the function fill_schema_table_by_open() did not read any data
from statistical tables.
</pre>
</div>
</content>
</entry>
</feed>
