Commit graph

70042 commits

Author SHA1 Message Date
Sergei Golubchik
6212cf86a2 galera fixes related to THD::LOCK_thd_kill
win
2021-02-02 14:08:07 +01:00
Sergei Golubchik
37e24970cb merge 2021-02-02 12:43:17 +01:00
Sergei Golubchik
2676c9aad7 galera fixes related to THD::LOCK_thd_kill
Since 2017 (c2118a08b1) THD::awake() no longer requires LOCK_thd_data.
It uses LOCK_thd_kill, and this latter mutex is used to prevent
a thread of dying, not LOCK_thd_data as before.
2021-02-02 10:02:17 +01:00
Oleksandr Byelkin
bbbe7e781f sync changes in oracle parser 2021-02-01 13:50:10 +01:00
Sergei Golubchik
60ea09eae6 Merge branch '10.2' into 10.3 2021-02-01 13:49:33 +01:00
Oleksandr Byelkin
17867608a2 ASAN heap-use-after-free in Item_exists_subselect::is_top_level_item
check that we can do type casting
2021-01-29 11:18:06 +01:00
Sergei Petrunia
33ede50f20 MDEV-22251: get_key_scans_params: Conditional jump or move depends on uninitialised value
Apply the patch based on the patch by Varun Gupta:

PARAM::is_ror_scan might be used unitialized when check_quick_select()
is invoked for a "degenerate" SEL_ARG tree (e.g. one having type
SEL_ARG::IMPOSSIBLE).

Make check_quick_select() always initialize PARAM::is_ror_scan.
2021-01-28 20:46:13 +03:00
Jan Lindström
20f6c403eb MDEV-20717 : Plugin system variables and activation options can break "mysqld --wsrep_recover"
Problem is that not all plugins are loaded when wsrep_recover is executed.
Thus, we allow unknown system variables and extra system variables during
wsrep_recover. Any unknown system variables would still be caught when
the server starts up normally after the SST.
2021-01-28 12:48:19 +02:00
Igor Babaev
bdae8bb6fd MDEV-24675 Server crash when table value constructor uses a subselect
This patch actually fixes the bug MDEV-24675 and the bug MDEV-24618:
Assertion failure when TVC uses a row in the context expecting scalar value

The cause of these bugs is the same wrong call of the function that fixes
value expressions in the value list of a table value constructor.
The assertion failure happened when an expression in the value list is of
the row type. In this case an error message was expected, but it was not
issued because the function fix_fields_if_needed() was called for to
check fields of value expressions in a TVC instead of the function
fix_fields_if_needed_for_scalar() that would also check that the value
expressions are are of a scalar type.
The first bug happened when a table value expression used an expression
returned by single-row subselect. In this case the call of the
fix_fields_if_needed_for_scalar virtual function must be provided with
and address to which the single-row subselect has to be attached.

Test cases were added for each of the bugs.

Approved by Oleksandr Byelkin <sanja@mariadb.com>
2021-01-26 18:22:39 -08:00
Nikita Malyavin
21809f9a45 MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failed
The assertion failed in handler::ha_reset upon SELECT under
READ UNCOMMITTED from table with index on virtual column.

This was the debug-only failure, though the problem is mush wider:
* MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw
 bitmap.
* read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP
* The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE
* The pointers to the stored MY_BITMAPs, like orig_read_set etc, and
 sometimes all_set and tmp_set, are assigned to the pointers.
* Sometimes tmp_use_all_columns is used to substitute the raw bitmap
 directly with all_set.bitmap
* Sometimes even bitmaps are directly modified, like in
TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called.

The last three bullets in the list, when used together (which is mostly
always) make the program flow cumbersome and impossible to follow,
notwithstanding the errors they cause, like this MDEV-17556, where tmp_set
pointer was assigned to read_set, write_set and vcol_set, then its bitmap
was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call,
and then bitmap_clear_all(&tmp_set) was applied to all this.

To untangle this knot, the rule should be applied:
* Never substitute bitmaps! This patch is about this.
 orig_*, all_set bitmaps are never substituted already.

This patch changes the following function prototypes:
* tmp_use_all_columns, dbug_tmp_use_all_columns
 to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map*
* tmp_restore_column_map, dbug_tmp_restore_column_maps to accept
 MY_BITMAP* instead of my_bitmap_map*

These functions now will substitute read_set/write_set/vcol_set directly,
and won't touch underlying bitmaps.
2021-01-27 00:50:55 +10:00
Jan Lindström
8cdeee177d MDEV-24509 : Warning: Memory not freed: 56 on SET @@global.wsrep_sst_auth
It seems that memory is not freed when updated value is NULL or
when wsrep is not initialized before shutdown.
2021-01-26 10:02:51 +02:00
Sergei Golubchik
29bbcac0ee MDEV-23328 Server hang due to Galera lock conflict resolution
mutex order violation here.
when wsrep bf thread kills a conflicting trx, the stack is

  wsrep_thd_LOCK()
  wsrep_kill_victim()
  lock_rec_other_has_conflicting()
  lock_clust_rec_read_check_and_lock()
  row_search_mvcc()
  ha_innobase::index_read()
  ha_innobase::rnd_pos()
  handler::ha_rnd_pos()
  handler::rnd_pos_by_record()
  handler::ha_rnd_pos_by_record()
  Rows_log_event::find_row()
  Update_rows_log_event::do_exec_row()
  Rows_log_event::do_apply_event()
  Log_event::apply_event()
  wsrep_apply_events()

and mutexes are taken in the order

  lock_sys->mutex -> victim_trx->mutex -> victim_thread->LOCK_thd_data

When a normal KILL statement is executed, the stack is

  innobase_kill_query()
  kill_handlerton()
  plugin_foreach_with_mask()
  ha_kill_query()
  THD::awake()
  kill_one_thread()

and mutexes are

  victim_thread->LOCK_thd_data -> lock_sys->mutex -> victim_trx->mutex

To fix the mutex order violation we kill the victim thd asynchronously,
from the manager thread
2021-01-24 11:35:55 +01:00
Sergei Golubchik
5d1db34585 cleanup: void hton::abort_transaction()
and void wsrep_innobase_kill_one_trx()

as their return values are never used.
Also remove redundant cast and checks that are always true
2021-01-24 11:35:55 +01:00
Sergei Golubchik
6a1cb449fe cleanup: remove slave background thread, use handle_manager thread instead 2021-01-24 11:35:55 +01:00
Sergei Golubchik
990eb09333 cleanup: fix and generalize handle_manager thread
* provide an argument to the callback
* don't ignore a callback request if it's already present in the queue
* initialize mutex/cond/in_use flag before starting the thread,
  in case the first callback queueing request arrives before
  handle_manager had time to initialize
* set/check abort_manager under a mutex, otherwise handle_manager
  thread might destroy LOCK_manager before stop_handle_manager
  released it
* signal COND on queueing a callback, stop cond_wait on callback request
* always start the thread, even if flush_time is 0
* but keep the old behavior in embedded (no replication, no galera)
* style cleanups (e.g. remove volatile for a variable protected by a mutex)
2021-01-24 11:35:55 +01:00
Sergei Golubchik
4a7e62296a don't allow KILL QUERY ID USER xxx 2021-01-24 11:35:55 +01:00
Daniel Black
29d9897fe2 MDEV-10272: add master host/port info to slave thread exit messages
Sample log error message generated:

2021-01-21  2:33:24 139912137520896 [Note] Slave SQL thread exiting, replication stopped in log 'master-bin.000001' at position 369
33:24 139912137520896 [Note] master was 127.0.0.1:16400
2021-01-21  2:33:24 139912137828096 [Note] Slave I/O thread exiting, read up to log 'master-bin.000001', position 369
2021-01-21  2:33:24 139912137828096 [Note] master was 127.0.0.1:16400

Based on work by Hartmut Holzgraefe.

Reviewer: knielsen@knielsen-hq.org, Andrei, Sachin
2021-01-22 10:06:33 +11:00
Sergei Golubchik
4e503aec7f MDEV-24593 Signal 11 when group by primary key of table joined to information_schema.columns
I_S tables were materialized too late, an attempt to use table
statistics before the table was created caused a crash.

Let's move table creation up. it only needs read_set to
be calculated properly, this happens in JOIN::optimize_inner(),
after semijoin transformation.

Note that tables are not populated at that point, so most of the
statistics would make no sense anyway. But at least field sizes
will be correct. And it won't crash.
2021-01-22 00:04:31 +01:00
Sujatha
eb75e8705d MDEV-8134: The relay-log is not flushed after the slave-relay-log.999999 showed
Problem:
========
Auto purge of relaylogs stops when relay-log-file is
'slave-relay-log.999999' and slave_parallel_threads is enabled.

Analysis:
=========
The problem is that in Relay_log_info::inc_group_relay_log_pos() function,
when two log names are compared via strcmp() function, it gives correct
result, when log name sequence numbers are of same digits(6 digits), But
when the number goes to 7 digits, a 999999 compares greater than
1000000, which is wrong, hence the bug.

Fix:
====
Extract the numeric extension part of the file name, convert it into
unsigned long and compare.

Thanks to David Zhao for the contribution.
2021-01-21 13:00:02 +05:30
Igor Babaev
b22285e482 MDEV-16940 Server crashes in unsafe_key_update upon attempt to update view
through 2nd execution of SP

This bug caused a server crash on the second call of any stored procedure
that contained an UPDATE statement over a multi-table view reporting an
error message at the prepare stage.
On the first call of the stored procedure after reporting an error at
the preparation stage of the UPDATE statement finished without calling
the function SELECT_LEX::save_prep_leaf_tables() for the SELECT used as
the definition of the view. This left the SELECT_LEX structure used by
the UPDATE statement in an inconsistent state for second call of the stored
procedure.

Approved by Oleksandr Byelkin <sanja@mariadb.com>
2021-01-19 08:04:02 -08:00
Alexey Botchkov
959dfac4d0 MDEV-19723 Assertion je->state == JST_KEY' failed while SELECT ST_GEOMFROMGEOJSON() and Assertion !mysql_bin_log.is_open() || thd.is_current_stmt_binlog_format_row()'
The invalid GeoJSON case wasn't handled here.
2021-01-19 15:29:03 +04:00
Rucha Deodhar
94890a749a MDEV-24179: Assertion `m_status == DA_ERROR || m_status == DA_OK ||
m_status == DA_OK_BULK' failed in Diagnostics_area::message()

Analysis: Assertion failure happens because we reach the maximum limit to
examine rows.
Fix: Return the error state.
2021-01-19 16:16:03 +05:30
sjaakola
7d04ce6a2d MDEV-21153 Replica nodes crash due to indexed virtual columns and FK cascading delete
Fix for MDEV-23033 fixes a problem in replication applying of transactions, which contain cascading foreign key delete for a table, which has indexed virtual column.
This fix adds slave_fk_event_map flag for table, to mark when the prelocking is needed for applying of a transaction.
See commit 608b0ee52e for more details.
However, this fix is targeted for async replication only, Rows_log_event::do_apply_event() has condition to rule out galera replication from the fix domain, and use cases suffering from MDEV-23033 and related MDEV-21153 will fail in galera cluster.

The fix in this commit removes the condition to rule out the setting of slave_fk_event_map flag from galera replication, and makes the fix in MDEV-23033 effective for galera replication as well.

Finally, a mtr test for virtual column support has been added. galera.galera_virtual_column.test has as first test a scenario from MDEV-21153

Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2021-01-19 12:12:10 +02:00
sjaakola
beaea31ab1 MDEV-23851 BF-BF Conflict issue because of UK GAP locks
Some DML operations on tables having unique secondary keys cause scanning
in the secondary index, for instance to find potential unique key violations
in the seconday index. This scanning may involve GAP locking in the index.
As this locking happens also when applying replication events in high priority
applier threads, there is a probabality for lock conflicts between two wsrep
high priority threads.

This PR avoids lock conflicts of high priority wsrep threads, which do
secondary index scanning e.g. for duplicate key detection.

The actual fix is the patch in sql_class.cc:thd_need_ordering_with(), where
we allow relaxed GAP locking protocol between wsrep high priority threads.
wsrep high priority threads (replication appliers, replayers and TOI processors)
are ordered by the replication provider, and they will not need serializability
support gained by secondary index GAP locks.

PR contains also a mtr test, which exercises a scenario where two replication
applier threads have a false positive conflict in GAP of unique secondary index.
The conflicting local committing transaction has to replay, and the test verifies
also that the replaying phase will not conflict with the latter repllication applier.
Commit also contains new test scenario for galera.galera_UK_conflict.test,
where replayer starts applying after a slave applier thread, with later seqno,
has advanced to commit phase. The applier and replayer have false positive GAP
lock conflict on secondary unique index, and replayer should ignore this.
This test scenario caused crash with earlier version in this PR, and to fix this,
the secondary index uniquenes checking has been relaxed even further.

Now innodb trx_t structure has new member: bool wsrep_UK_scan, which is set to
true, when high priority thread is performing unique secondary index scanning.
The member trx_t::wsrep_UK_scan is defined inside WITH_WSREP directive, to make
it possible to prepare a MariaDB build where this additional trx_t member is
not present and is not used in the code base. trx->wsrep_UK_scan is set to true
only for the duration of function call for: lock_rec_lock() trx->wsrep_UK_scan
is used only in lock_rec_has_to_wait() function to relax the need to wait if
wsrep_UK_scan is set and conflicting transaction is also high priority.

Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2021-01-18 08:09:06 +02:00
Dmitry Shulga
f130adbf35 MDEV-23666: Assertion `m_cpp_buf <= ptr && ptr <= m_cpp_buf + m_buf_length' failed in Lex_input_stream::body_utf8_append
On parsing statements for which a starting backtick (`) delimiter doesn't have
a corresponding ending backtick, a current pointer to a position inside a
pre-processed buffer could go beyond the end of the buffer.

This bug report caused by the commit d496765903
  "MDEV-22022 Various mangled SQL statements will crash 10.3 to 10.5 debug builds".

In order to fix the issue both pointers m_ptr and m_cpp_ptr must be
rolled back to previous position in raw input and pre-processed input streams
correspondingly in case end of query reached during parsing.
2021-01-14 14:31:20 +07:00
Rucha Deodhar
fb9a9599bc MDEV-24387: Wrong number of decimal digits in certain UNION/Subqery
constellation

Analysis: The decimals is set to NOT_FIXED_DEC for Field_str even if it is
NULL. Unsigned has decimals=0. So Type_std_attributes::decimals is set to 39
(maximum between 0 and 39). This results in incorrect number of decimals
when we have union of unsigned and NULL type.

Fix: Check if the field is created from NULL value. If yes, set decimals to 0
otherwise set it to NOT_FIXED_DEC.
2021-01-13 19:24:05 +05:30
Dmitry Shulga
9e4a5a81fc MDEV-24208 SHOW RELAYLOG EVENTS command is not supported in the prepared statement protocol yet
Added sending of metadata in response to preparing request for
the commands SQLCOM_SHOW_BINLOG_EVENTS, SQLCOM_SHOW_RELAYLOG_EVENTS
2021-01-13 16:16:13 +07:00
Aleksey Midenkov
59998d3480 MDEV-23446 Missed error code fix 2021-01-12 18:44:24 +03:00
Varun Gupta
ab271ee7e2 MDEV-23826: ORDER BY in view definition leads to wrong result with GROUP BY on query using view
Introduced val_time_packed and val_datetime_packed  functions for Item_direct_ref
to make sure to get the value from the item it is referring to.

The issue for incorrect result was that the item was getting its value
from the temporary table rather than from the view.
2021-01-12 18:47:39 +05:30
Varun Gupta
3b94309a6c MDEV-23753: SIGSEGV in Column_stat::store_stat_fields
For EITS collection min and max fields are allocated for each column
that is set in the read_set bitmap of a table. This allocation of min and max
fields happens inside alloc_statistics_for_table.

For a partitioned table ha_rnd_init is called inside the function
collect_statistics_for_table which sets the read_set bitmap for the columns
inside the partition expression. This happens only when there is a write lock
on the partitioned table.
But the allocation happens before this, so min and max fields are not allocated
for the columns involved in the partition expression.
This resulted in a crash, as the EITS statistics were collected but there was
no min and max field to store the value to.

The fix would be to call ha_rnd_init inside the function alloc_statistics_for_table
that would make sure that min and max fields are allocated for the columns
involved in the partition expression.
2021-01-12 18:47:35 +05:30
Sergei Golubchik
3ffd5f28f0 MDEV-17227 Server crash in TABLE_SHARE::init_from_sql_statement_string upon table discovery with non-existent database
* failed init_from_binary_frm_image can clear share->db_plugin,
  don't use it on the error path
* cleanup the test a bit
2021-01-12 10:25:04 +01:00
Sergei Golubchik
f144ce2cfa MDEV-20763 Table corruption or Assertion `btr_validate_index(index, 0, false)' failed in row_upd_sec_index_entry with virtual column and EMPTY_STRING_IS_NULL SQL mode
unset empty_string_is_null mode when parsing generated columns in a table,
this mode affects pasring.
2021-01-12 10:25:04 +01:00
Sergei Golubchik
d463677f7e failing to parse an SP should not abort information_schema.routines 2021-01-12 10:25:03 +01:00
Sergei Golubchik
f7ff8f5dd9 MDEV-24524 Assertion `ls->length < 0xFFFFFFFFL && ((ls->length == 0 && !ls->str) || ls->length == strlen(ls->str))' failed in String::append on SELECT from I_S
don't expect return type of a stored function to be valid.
it's read from a table, so can be messed with.
it even can contain \0 bytes in the middle of the type name
2021-01-12 10:25:03 +01:00
Sergei Golubchik
ad9a140d9b MDEV-14884 Failed to enable encryption of temporary files in mariadb 10.3.3
enable the encryption (and abort on failure) after printing --help,
not before
2021-01-11 21:54:48 +01:00
Sergei Golubchik
0d8bd7cc3a MDEV-18428 Memory: If transactional=0 is specified in CREATE TABLE, it is not possible to ALTER TABLE
* be strict in CREATE TABLE, just like in ALTER TABLE, because
  CREATE TABLE, just like ALTER TABLE, can be rolled back for any engine
* but don't auto-convert warnings into errors for engine warnings
  (handler::create) - this matches ALTER TABLE behavior
* and not when creating a default record, these errors are handled
  specially (and replaced with ER_INVALID_DEFAULT)
* always issue a Note when a non-unique key is truncated, because it's
  not a Warning that can be converted to an Error. Before this commit
  it was a Note for blobs and a Warning for all other data types.
2021-01-11 21:54:47 +01:00
Sergei Golubchik
6f707430e5 cleanup: copy RAII helpers from 10.5, cleanup test 2021-01-11 21:54:47 +01:00
Sergei Golubchik
4568a72ce4 don't do a warning for bad table options in replication slave thread
otherwise ALTER TABLE can break replication
2021-01-11 21:54:47 +01:00
Sergei Golubchik
674be2fd82 MDEV-18428 Memory: If transactional=0 is specified in CREATE TABLE, it is not possible to ALTER TABLE
fix "engine does not support TRANSACTIONAL=1" error message to
match user input
2021-01-11 21:54:47 +01:00
Sergei Golubchik
22b171d304 MDEV-17852 Altered connection limits for user have no effect
update mqh in struct user_conn after taking it from the cache
2021-01-11 21:54:47 +01:00
Sergei Golubchik
fc0d9a470c MDEV-22966 Server crashes or hangs with SET ROLE when started with skip-grant-tables 2021-01-11 21:54:47 +01:00
Sergei Golubchik
63f9192787 MDEV-17251 SHOW STATUS unnecessary calls calc_sum_of_all_status
1. only call calc_sum_of_all_status() if a global
   SHOW_xxx_STATUS variable is to be returned
2. only lock LOCK_status when copying global_status_var,
   but not when iterating all threads
2021-01-11 21:54:47 +01:00
Sergei Golubchik
4c448836d4 MDEV-12161 Can't specify collation for virtual columns
sql standard (2016) allows <collate clause> in two places in the
<column definition> - as a part of the <data type> or at the very end.

Let's do that too.

Side effect: in column/SP declaration `COLLATE cs_coll` automatically
implies `CHARACTER SET cs` (unless charset was specified explicitly).
See changes in sp-ucs2.result
2021-01-11 21:54:47 +01:00
Sergei Golubchik
9b750dcbd8 MDEV-23536 Race condition between KILL and transaction commit
Server part:
  kill_handlerton() was accessing thd->ha_data[] for some other thd,
  while it could be concurrently modified by its owner thd.

  protect thd->ha_data[] modifications with a mutex.
  require this mutex when accessing thd->ha_data[] from kill_handlerton.

InnoDB part:
  on close_connection, detach trx from thd before freeing the trx
2021-01-11 21:54:47 +01:00
Sergei Golubchik
66f4900b51 Revert "MDEV-23536 : Race condition between KILL and transaction commit"
This reverts the server part of the commit 775fccea0
but keeps InnoDB part (which reverted MDEV-17092 5530a93f4).

So after this both MDEV-23536 and MDEV-17092 are reverted,
and the original bug is resurrected.
2021-01-11 21:54:47 +01:00
Marko Mäkelä
5a1a714187 Merge 10.2 into 10.3 (except MDEV-17556)
The fix of MDEV-17556 (commit e25623e78a
and commit 61a362c949) has been
omitted due to conflicts and will have to be applied separately later.
2021-01-11 09:41:54 +02:00
Jan Lindström
775fccea0c MDEV-23536 : Race condition between KILL and transaction commit
A race condition may occur between the execution of transaction commit,
and an execution of a KILL statement that would attempt to abort that
transaction.

MDEV-17092 worked around this race condition by modifying InnoDB code.
After that issue was closed, Sergey Vojtovich pointed out that this
race condition would better be fixed above the storage engine layer:

If you look carefully into the above, you can conclude that
thd->free_connection() can be called concurrently with
KILL/thd->awake(). Which is the bug. And it is partially fixed in
THD::~THD(), that is destructor waits for KILL completion:

Fix: Add necessary mutex operations to THD::free_connection()
and move WSREP specific code also there. This ensures that no
one is using THD while we do free_connection(). These mutexes
will also ensures that there can't be concurrent KILL/THD::awake().

innobase_kill_query
  We can now remove usage of trx_sys_mutex introduced on MDEV-17092.

trx_t::free()
  Poison trx->state and trx->mysql_thd

This patch is validated with an RQG run similar to the one that
reproduced MDEV-17092.
2021-01-08 17:11:54 +02:00
Marko Mäkelä
cd1e5d65c6 MDEV-19838 fixup: clang -Wunused-const-variable 2021-01-08 08:10:18 +02:00
Nikita Malyavin
e25623e78a MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failed
The assertion failed in handler::ha_reset upon SELECT under
READ UNCOMMITTED from table with index on virtual column.

This was the debug-only failure, though the problem is mush wider:
* MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw
 bitmap.
* read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP
* The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE
* The pointers to the stored MY_BITMAPs, like orig_read_set etc, and
 sometimes all_set and tmp_set, are assigned to the pointers.
* Sometimes tmp_use_all_columns is used to substitute the raw bitmap
 directly with all_set.bitmap
* Sometimes even bitmaps are directly modified, like in
TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called.

The last three bullets in the list, when used together (which is mostly
always) make the program flow cumbersome and impossible to follow,
notwithstanding the errors they cause, like this MDEV-17556, where tmp_set
pointer was assigned to read_set, write_set and vcol_set, then its bitmap
was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call,
and then bitmap_clear_all(&tmp_set) was applied to all this.

To untangle this knot, the rule should be applied:
* Never substitute bitmaps! This patch is about this.
 orig_*, all_set bitmaps are never substituted already.

This patch changes the following function prototypes:
* tmp_use_all_columns, dbug_tmp_use_all_columns
 to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map*
* tmp_restore_column_map, dbug_tmp_restore_column_maps to accept
 MY_BITMAP* instead of my_bitmap_map*

These functions now will substitute read_set/write_set/vcol_set directly,
and won't touch underlying bitmaps.
2021-01-08 16:04:29 +10:00
Oleksandr Byelkin
188b328335 Urgent fix of MDEV-23446 fix:
Use the same variable in both scopes (from where we have "goto error" and target of the goto)
2021-01-07 09:29:10 +01:00