The test could fail sporadically because of not anticipated
race on slave between CREATE and ALTER queries.
Fixed to synchronize slave and master wrt CREATE.
save_restore_context_apply_event(): Because compilers cannot infer
that ev->apply_event(rgi) will not affect ev->get_type_code(),
let us test that condition only once and allow the compiler to
emit a tail call.
Also, replace a goto with an early return for error handling.
The added by MDEV-11675 assert is incorrected assuming
a replayed from binlog transaction can't contain invoke
a FD event's apply method.
In fact it can do that through BINLOG event.
The test case like
BEGIN;
INSERT INTO t1 VALUES(10);
BINLOG '
SOgWTg8BAAAAbgAAAHIAAAAAAAQANS42LjMtbTUtZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABI6BZOEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAAAVAYI8=';
is provided (by yet to merged atm) MDEV-27536 fixes.
The assert is removed.
- Store the deferred tablespace name while loading the tablespace
for backup process.
- Mariabackup stores the list of space ids which has page0 INIT_PAGE
records. backup_first_page_op() and first_page_init() was introduced
to track the page0 INIT_PAGE records.
- backup_file_op() and log_file_op() was changed to handle
FILE_MODIFY redo log records. It is used to identify the
deferred tablespace space id.
- Whenever file operation redo log was processed by backup,
backup_file_op() should check whether the space name exist
in deferred tablespace. If it is then it needs to store the
space id, name when FILE_MODIFY, FILE_RENAME redo log processed
and it should delete the tablespace name from defer list in other
cases.
- backup_fix_ddl() should check whether deferred tablespace has
any page0 init records. If it is then consider the tablespace
as newly created tablespace. If not then backup should try
to reload the tablespace with SRV_BACKUP_NO_DEFER mode to
avoid the deferring of tablespace.
This happens for example if one installs into home directory of a user
C:\Users\<username>\mariadb
The reason is that the service user "NT SERVICE\<service_name>" does
not have read and execute permissions for service executable mysqld.exe
in this directory.
Moreover, it would not have read permissions for server.dll loaded by the
exe, or to plugin directory, where plugins may reside.
The fix is to give service users read and execute permissions to bin, share, and
lib\plugin subdirectories.
The permission setting is doneby mysql_install_db.exe, but also in MSI.
It is important to do that in MSI, as we want permissions to survive
the MSI upgrade.
This patch fixes two issues:
First, it fixes test failure due to GTID List events
having inconsistent ordering of domain ids. In
particular, this patch ensures that a GTID list log
event will have its GTIDs ordered by domain id
(ascending) followed by sequence number (ascending).
Second, it fixes an assert which could use an
unintialized variable.
Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>
when it's run directly after main.mysql_json_mysql_upgrade
because mysqld--help-aria starts a second mysqld that reads the plugin
table, so it has to be flushed and closed at that time.
that was permanently disabled in a merge mistake. also
* use auth_test_plugin to test dumping of plugins and user auth,
as the original test intended
* s/USER/foobar/ to make a username searchable
accessing freed memory.
Before XMLCOL::WriteColumn() Tdbp->Clist gets assigned
a nodelist in
Clist = RowNode->SelectNodes(g, Colname, Clist);
which is RowNode->Doc->Xop->nodesetval.
In XMLCOL::WriteColumn()
ValNode = ColNode->SelectSingleNode(g, Xname, Vxnp);
calls LIBXMLDOC::GetNodeList() again, which frees the previous
XPath object Xop and replaces it with a new one.
In this case RowNode->Doc == ColNode->Doc, so Clist->Listp
points to a freed memory now.
- Revert wrongly record embedded result files. These were either
recorded with normal server (not embedded) or an embedded server
with not default compile option. This can be seen that the committed
result file had replication variables which should never happen.
- Reverted back change of include/is_embedded.inc. One cannot check for
$MYSQL_EMBEDDED as this only tells if there exists an embedded
server, not if the current server we are testing is the embedded
server. This could easily be verified by doing
'mtr sys_vars.sysvars_server_embedded'. This would fail with a wrong
result instead of being marked as skipped as --embedded was not
used.
This happens when compiled with HAVE_EMBEDDED_PRIVILEGE_CONTROL.
There is a lot of other problems with the above option that should
be fixed at some point
Even though Apple Xcode is based on and similar to Clang,
it does not support the asm goto construct which was added
in commit 668a5f3d12 (MDEV-26720)
to work around a compiler deficiency that results in suboptimal
code being generated for IA-32 and AMD64.
We will disable this manual optimization if __APPLE_CC__ is defined.
Similar constructs are also used in sync/srw_lock.cc, but that code
is not used on Apple, because we have not implemented a Linux futex
compatible interface on Apple macOS.
Thanks to Valerii Kravchuk for reporting and testing this.
This commit implements two phase binloggable ALTER.
When a new
@@session.binlog_alter_two_phase = YES
ALTER query gets logged in two parts, the START ALTER and the COMMIT
or ROLLBACK ALTER. START Alter is written in binlog as soon as
necessary locks have been acquired for the table. The timing is
such that any concurrent DML:s that update the same table are either
committed, thus logged into binary log having done work on the old
version of the table, or will be queued for execution on its new
version.
The "COMPLETE" COMMIT or ROLLBACK ALTER are written at the very point
of a normal "single-piece" ALTER that is after the most of
the query work is done. When its result is positive COMMIT ALTER is
written, otherwise ROLLBACK ALTER is written with specific error
happened after START ALTER phase.
Replication of two-phase binloggable ALTER is
cross-version safe. Specifically the OLD slave merely does not
recognized the start alter part, still being able to process and
memorize its gtid.
Two phase logged ALTER is read from binlog by mysqlbinlog to produce
BINLOG 'string', where 'string' contains base64 encoded
Query_log_event containing either the start part of ALTER, or a
completion part. The Query details can be displayed with `-v` flag,
similarly to ROW format events. Notice, mysqlbinlog output containing
parts of two-phase binloggable ALTER is processable correctly only by
binlog_alter_two_phase server.
@@log_warnings > 2 can reveal details of binlogging and slave side
processing of the ALTER parts.
The current commit also carries fixes to the following list of
reported bugs:
MDEV-27511, MDEV-27471, MDEV-27349, MDEV-27628, MDEV-27528.
Thanks to all people involved into early discussion of the feature
including Kristian Nielsen, those who helped to design, implement and
test: Sergei Golubchik, Andrei Elkin who took the burden of the
implemenation completion, Sujatha Sivakumar, Brandon
Nesterenko, Alice Sherepa, Ramesh Sivaraman, Jan Lindstrom.
Most of this was likely already fixed by MDEV-27017.
On one implementation of the AMD64 ISA, the test
innodb_fts.concurrent_insert would still occasionally hang,
with both dict_sys_t::evict_table_LRU() and
dict_index_set_merge_threshold() waiting in dict_sys_t::lock()
several threads waiting in dict_sys_t::freeze(),
no thread holding exclusive dict_sys.latch and also no thread
in the stack traces apparently holding any dict_sys.latch,
even though dict_sys.latch_readers == 1.
To prevent this scenario, we will remove the dict_sys.latch
acquisition from dict_index_set_merge_threshold(). It is actually
not needed, because dict_sys.sys_indexes will not change after
InnoDB startup. The SYS_INDEXES leaf page will be sufficiently
protected by the page latch.
There potentially is a bug in the srw_lock implementation,
which will have to be investigated further.
In commit 685d958e38 (MDEV-14425)
a bug was introduced to mariadb-backup --backup for the case when
the log is wrapping around to log_sys.START_OFFSET (12288).
This could also cause a "Missing FILE_CHECKPOINT" error during
mariadb-backup --prepare, in case the log copying resumed after
the server had produced a multiple of innodb_log_file_size-12288
bytes of more log so that the last mini-transaction would end
exactly at the end of the log file.
xtrabackup_copy_logfile(): If the log wraps around, read everything
to the end of the log file, and then the rest from log_sys.START_OFFSET.
