summaryrefslogtreecommitdiff
path: root/mysql-test/main/partition_symlink.test
diff options
context:
space:
mode:
authorBrandon Nesterenko <brandon.nesterenko@mariadb.com>2019-12-17 15:23:55 +0530
committerBrandon Nesterenko <brandon.nesterenko@mariadb.com>2022-07-25 16:26:53 -0600
commit555c12a541c21ed71dc40ae7d246c150a2d2b06b (patch)
treed3b0aba6745dd5a4c72822cd0f5a0be12c775cf7 /mysql-test/main/partition_symlink.test
parent46ff660883aade25f16abb13588f0a1934e9da56 (diff)
downloadmariadb-git-555c12a541c21ed71dc40ae7d246c150a2d2b06b.tar.gz
MDEV-21087/MDEV-21433: ER_SLAVE_INCIDENT arrives at slave without failure specifics
Problem: ======= This patch addresses two issues: 1. An incident event can be incorrectly reported for transactions which are rolled back successfully. That is, an incident event should only be generated for failed “non-transactional transactions” (i.e., those which modify non-transactional tables) because they cannot be rolled back. 2. When the mariadb slave (error) stops at receiving the incident event there's no description of what led to it. Neither in the event nor in the master's error log. Solution: ======== Before reporting an incident event for a transaction, first validate that it is “non-transactional” (i.e. cannot be safely rolled back). To determine if a transaction is non-transactional, lex->stmt_accessed_table(LEX::STMT_WRITES_NON_TRANS_TABLE) is used because it is set previously in THD::decide_logging_format(). Additionally, when an incident event is written, write an error message to the server’s error log to indicate the underlying issue. Reviewed by: =========== Andrei Elkin <andrei.elkin@mariadb.com>
Diffstat (limited to 'mysql-test/main/partition_symlink.test')
0 files changed, 0 insertions, 0 deletions