1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-16 00:42:55 +03:00
Commit Graph

199 Commits

Author SHA1 Message Date
80459bcbd4 Merge 10.4 into 10.5 2021-03-27 17:37:42 +02:00
7ae37ff74f Merge 10.3 into 10.4 2021-03-27 17:12:28 +02:00
3157fa182a Merge 10.2 into 10.3 2021-03-27 16:11:26 +02:00
8f7a6cde58 MDEV-24767 Wrong result when forced BNLH is used for join supported
by compound index

This typo bug may lead to wrong result sets for equi-join queries where
the join operation is supported by a compound index such that the order of
its components differs from the order of the corresponding columns in
the table the index belongs to. The bug manifests itself only when usage
of the BNLH algorithm is forced.

The fix for the bug was provided by Chu Huaxing.
2021-03-22 22:04:54 -07:00
be881ec457 Merge 10.4 into 10.5 2021-03-19 13:09:21 +02:00
44d70c01f0 Merge 10.3 into 10.4 2021-03-19 11:42:44 +02:00
19052b6deb Merge 10.2 into 10.3 2021-03-18 12:34:48 +02:00
90780bb5a9 MDEV-21104 Wrong result (extra rows and wrong values) with incremental BNLH
This bug could affect multi-way join queries with embedded outer joins that
contained a conjunctive IS NULL predicate over a non-nullable column from
inner table of an outer join. The predicate could occur in WHERE condition
or in ON condition. Due to this bug a wrong result set could be returned by
the query. The bug manifested itself only when join buffers were employed
for join operations.

The problem appeared because
- a bug in the function JOIN_CACHE::get_match_flag_by_pos that not always
  returned proper match flags for embedding outer joins stored together
  with table rows put a join buffer.
- bug in the function JOIN_CACHE::join_matching_records that not always
  correctly determined that a row from the buffer could be skipped due
  to applied 'not_exists' optimization.
Example:
  SELECT * FROM t1 LEFT JOIN ((t2 LEFT JOIN t3 ON c = d) JOIN t4) ON b = e
    WHERE e IS NULL;

The patch introduces a new function that finds the match flag for a record
from join buffer specifying the buffer where this flag has to be found.
The function is called JOIN_CACHE::get_match_flag_by_pos_from_join_buffer().
Now this function rather than JOIN_CACHE::get_match_flag_by_pos() is used
in JOIN_CACHE::skip_if_matched() to check whether a record from the join
buffer must be ignored when extending the record by null complements.
Also the code of the function JOIN_CACHE::skip_if_not_needed_match() has
been changed. The function checks whether a record from the join buffer
still may produce some useful extensions.
Also some clarifying comments has been added.

Approved by monty@mariadb.com.
2021-03-10 17:28:40 -08:00
133b4b46fe Merge 10.4 into 10.5 2020-11-03 16:24:47 +02:00
533a13af06 Merge 10.3 into 10.4 2020-11-03 14:49:17 +02:00
c7f322c91f Merge 10.2 into 10.3 2020-11-02 15:48:47 +02:00
8036d0a359 MDEV-22387: Do not violate __attribute__((nonnull))
This follows up commit
commit 94a520ddbe and
commit 7c5519c12d.

After these changes, the default test suites on a
cmake -DWITH_UBSAN=ON build no longer fail due to passing
null pointers as parameters that are declared to never be null,
but plenty of other runtime errors remain.
2020-11-02 14:19:21 +02:00
fad47df995 Merge branch '10.4' into 10.5 2020-03-11 17:52:49 +01:00
0d837e8153 perfschema table io instrumentation related changes 2020-03-10 19:24:23 +01:00
7c58e97bf6 perfschema memory related instrumentation changes 2020-03-10 19:24:22 +01:00
2fb881df1d MDEV-21610 Different query results from 10.4.11 to 10.4.12
This patch fixes the following defects/bugs.
1. If BKA[H] algorithm was used to join a table for which the optimizer
had decided to employ a rowid filter the filter actually was not built.
2. The patch for the bug MDEV-21356 that added the code canceling pushing
rowid filter into an engine for the table joined with employment of
BKA[H] and MRR was not quite correct for Innodb engine because this
cancellation was done after InnoDB code had already bound the the pushed
filter to internal InnoDB structures.
2020-02-18 22:51:07 -08:00
2df2238cb8 Lintian complains on spelling error
The lintian check complains on spelling error:
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/95739
2019-12-02 12:41:13 +02:00
4a3d51c76c Merge branch '10.2' into 10.3 2019-06-14 07:36:47 +02:00
50653e021f Merge branch '10.1' into 10.2 2019-06-13 16:42:21 +02:00
5b65d61d93 Merge branch '5.5' into 10.1 2019-06-12 22:54:46 +02:00
eb09580b67 MDEV-19588 Wrong results from query, using left join.
This bug could happen when queries with nested outer joins were
executed employing join buffers. At such an execution if the method
JOIN_CACHE::join_records() is called when a join buffer has become
full no 'first_unmatched' field should be cleaned up in the JOIN_TAB
structure to which the join cache with this buffer is attached.
2019-05-28 14:53:08 -07:00
be85d3e61b Merge 10.2 into 10.3 2019-05-14 17:18:46 +03:00
26a14ee130 Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
f177f125d4 Merge branch '5.5' into 10.1 2019-05-11 19:15:57 +03:00
17b4f99928 Update FSF address
This commit is based on the work of Michal Schorm, rebased on the
earliest MariaDB version.

Th command line used to generate this diff was:

find ./ -type f \
  -exec sed -i -e 's/Foundation, Inc., 59 Temple Place, Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \
  -exec sed -i -e 's/Foundation, Inc. 59 Temple Place.* Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \
  -exec sed -i -e 's/MA.*.....-1307.*USA/MA 02110-1335 USA/g' {} \; \
  -exec sed -i -e 's/Foundation, Inc., 59 Temple/Foundation, Inc., 51 Franklin/g' {} \; \
  -exec sed -i -e 's/Place, Suite 330, Boston, MA.*02111-1307.*USA/Street, Fifth Floor, Boston, MA 02110-1335 USA/g' {} \; \
  -exec sed -i -e 's/MA.*.....-1307/MA 02110-1335/g' {} \;
2019-05-10 20:52:00 +03:00
58721c3e38 MDEV-16286 Killed CREATE SEQUENCE leaves sequence in unusable state
Fixed by deleting the sequence if we where not able to initialize it

I also noticed that we didn't always set the error message when
check_killed(), which could lead to aborted queries without error
beeing properly set. Fixed by default setting error message if
check_error() noticed that killed had been called.
This allowed me to remove a lot of calls to thd->send_kill_message().
2018-05-27 19:47:17 +03:00
30ebc3ee9e Add likely/unlikely to speed up execution
Added to:
- if (error)
- Lex
- sql_yacc.yy and sql_yacc_ora.yy
- In header files to alloc() calls
- Added thd argument to thd_net_is_killed()
2018-05-07 00:07:32 +03:00
b006d2ead4 Merge bb-10.2-ext into 10.3 2018-02-15 10:22:03 +02:00
4771ae4b22 Merge branch 'github/10.1' into 10.2 2018-02-06 14:50:50 +01:00
6c279ad6a7 MDEV-15091 : Windows, 64bit: reenable and fix warning C4267 (conversion from 'size_t' to 'type', possible loss of data)
Handle string length as size_t, consistently (almost always:))
Change function prototypes to accept size_t, where in the past
ulong or uint were used. change local/member variables to size_t
when appropriate.

This fix excludes rocksdb, spider,spider, sphinx and connect for now.
2018-02-06 12:55:58 +00:00
d4df7bc9b1 Merge branch 'github/10.0' into 10.1 2018-02-02 10:09:44 +01:00
d833bb65d5 Merge remote-tracking branch '5.5' into 10.0 2018-01-24 12:29:31 +02:00
444587d8a3 BIT field woes
* get_rec_bits() was always reading two bytes, even if the
  bit field contained only of one byte
* In various places the code used field->pack_length() bytes
  starting from field->ptr, while it should be field->pack_length_in_rec()
* Field_bit::key_cmp and Field_bit::cmp_max passed field_length as
  an argument to memcmp(), but field_length is the number of bits!
2018-01-16 23:29:48 +01:00
87933d5261 Handle failures from malloc
Most "new" failures fixed in the following files:
- sql_select.cc
- item.cc
- item_func.cc
- opt_subselect.cc

Other things:
- Allocate udf_handler strings in mem_root
  - Required changes in sql_string.h
- Add mem_root as argument to some new [] calls
- Mark udf_handler strings as thread specific
- Removed some comment blocks with code
2017-11-17 07:30:05 +02:00
835cbbcc7b Merge remote-tracking branch 'origin/bb-10.2-ext' into 10.3
TODO: enable MDEV-13049 optimization for 10.3
2017-10-30 20:47:39 +04:00
dc93ce8dea Windows : Fix truncation warnings in sql/ 2017-10-10 06:19:50 +00:00
2c1067166d Merge bb-10.2-ext into 10.3 2017-10-04 08:24:06 +03:00
7354dc6773 MDEV-13384 - misc Windows warnings fixed 2017-09-28 17:20:46 +00:00
4a32e2395e Merge bb-10.2-ext into 10.3 2017-09-25 22:05:56 +03:00
7dcb8816a1 Merge 10.1 into 10.2 2017-09-25 13:46:54 +03:00
f91eb71e1c MDEV-8840: ANALYZE FORMAT=JSON produces wrong data with BKA
The issue was that r_loops, r_rows and r_filtered in ANALYZE FORMAT= JSON were not
calculated for the table on which we were performing the MRR scan in the BKA join
Fixed this by adding respective counter in the JOIN_TAB_SCAN_MRR::open and JOIN_TAB_SCAN_MRR::next
2017-09-24 23:37:57 +05:30
5dd8e1bf2d simplify READ_RECORD usage NFC
READ_RECORD read_record;
...
// this
// read_record.read_record(&read_record);
// becomes just
read_record.read_record();
2017-08-31 13:46:30 +04:00
4aaa38d26e Enusure that my_global.h is included first
- Added sql/mariadb.h file that should be included first by files in sql
  directory, if sql_plugin.h is not used (sql_plugin.h adds SHOW variables
  that must be done before my_global.h is included)
- Removed a lot of include my_global.h from include files
- Removed include's of some files that my_global.h automatically includes
- Removed duplicated include's of my_sys.h
- Replaced include my_config.h with my_global.h
2017-08-24 01:05:44 +02:00
da4d71d10d Merge branch '10.1' into 10.2 2017-03-30 12:48:42 +02:00
f0ec34002a Correct FSF address 2017-03-10 18:21:29 +01:00
ad0c218a44 Merge 10.0 into 10.1
Also, implement MDEV-11027 a little differently from 5.5 and 10.0:

recv_apply_hashed_log_recs(): Change the return type back to void
(DB_SUCCESS was always returned).

Report progress also via systemd using sd_notifyf().
2017-03-09 08:53:08 +02:00
1acfa942ed Merge branch '5.5' into 10.0 2017-03-03 01:37:54 +02:00
8897b50dca MDEV-11525 Assertion `cp + len <= buff + buff_size' failed in JOIN_CACHE::write_record_data
Workaround for join_cache + index on vcols + keyread bug.
Initialize the record to avoid caching garbage in non-read fields.

A proper fix (do not cache non-read fields at all) is done in 10.2
in commits 5d7607f340f..8d99166c697
2017-02-27 12:35:10 +01:00
5d7607f340 cleanup: style fixes, sql_join_cache.cc 2017-02-13 18:12:04 +01:00
0e401bf7bf bugfix: move vcol calculations down into the handler
This fixes a bug where handler::read_range_first (for example)
needed to compare vcol values that were not calculated yet.

As a bonus it fixes few cases where vcols were calculated twice
2016-12-12 20:27:38 +01:00