11 Commits

Author	SHA1	Message	Date
Oleksandr Byelkin	7841a7eb09	Merge branch '10.3' into 10.4	2021-07-31 22:59:58 +02:00
Sergei Golubchik	6190a02f35	Merge branch '10.2' into 10.3	2021-07-21 20:11:07 +02:00
Oleksandr Byelkin	b7362d5fbc	Merge branch '10.3' into 10.4	2020-03-11 14:28:24 +01:00
Oleksandr Byelkin	3c9bc0ce19	Merge branch '10.2' into 10.3	2020-03-11 14:05:41 +01:00
Sergei Golubchik	244f0e6dd8	Merge branch '10.3' into 10.4	2019-09-06 11:53:10 +02:00
Monty	a071e0e029	Merge branch '10.2' into 10.3	2019-09-03 13:17:32 +03:00
Marko Mäkelä	f98bb23168	Merge 10.3 into 10.4	2019-05-29 22:17:00 +03:00
Marko Mäkelä	90a9193685	Merge 10.2 into 10.3	2019-05-29 11:32:46 +03:00
Vladislav Vaintroub	ad36d38024	MDEV-19235 MariaDB Server compiled for 128 Indexes crashes at startup ... With MAX_INDEXIES=64(default), key_map=Bitmap<64> is just a wrapper around ulonglong and thus "trivial" (can be bzero-ed, or memcpy-ed, and stays valid still) With MAX_INDEXES=128, key_map = Bitmap<128> is not a "trivial" type anymore. The implementation uses MY_BITMAP, and MY_BITMAP contains pointers which make Bitmap invalid, when it is memcpy-ed/bzero-ed. The problem in 10.4 is that there are many new key_map members, inside TABLE or KEY, and those are often memcopied and bzeroed The fix makes Bitmap "trivial", by inlining most of MY_BITMAP functionality. pointers/heap allocations are not used anymore.	2019-05-09 18:58:16 +02:00
Oleksandr Byelkin	b4ee699a89	MDEV-11975: SQLCOM_PREPARE of EXPLAIN & ANALYZE statement do not return correct metadata info ... Added metadate info after prepare EXPLAIN/ANALYZE.	2018-04-25 17:16:33 +02:00
Michael Widenius	a7abddeffa	Create 'main' test directory and move 't' and 'r' there	2018-03-29 13:59:44 +03:00