savepoints and replication

Bug #1483251 reported by Vlad Lesin
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.6
Incomplete
High
Vlad Lesin
5.7
Incomplete
High
Vlad Lesin

Bug Description

This bug report is a summary about savepoints in replication.

There are two bugs reported earlier: https://bugs.launchpad.net/percona-server/+bug/1438990, https://bugs.launchpad.net/percona-server/+bug/1438990.

The full description of bug #1438990 and the way to fix it can be found here https://github.com/percona/percona-server/pull/58.

The full description of bug #1464468 is here: https://bugs.launchpad.net/percona-server/+bug/1464468/comments/1 , https://bugs.launchpad.net/percona-server/+bug/1464468/comments/2 (see also fixes here https://github.com/percona/percona-server/pull/113 and here https://github.com/percona/percona-server/pull/116 ).

The suggested fixes here also fixes both bugs.

After fixing these two bugs we have the following issues with binary logs:

#### Consider Simplified testcase.

--delimiter |
CREATE TRIGGER t_insert_trig AFTER INSERT ON t
    FOR EACH ROW
        BEGIN
                    SAVEPOINT savepoint_1;
                    SET @a = 10;
        END |
--delimiter ;

INSERT INTO t VALUES (2);
INSERT INTO t VALUES (3);

master-bin.000001 # Query # # BEGIN
master-bin.000001 # Table_map # # table_id: # (test.t)
master-bin.000001 # Write_rows # # table_id: #
master-bin.000001 # Query # # SAVEPOINT `savepoint_1`
master-bin.000001 # Table_map # # table_id: # (test.t)
master-bin.000001 # Xid # # COMMIT /* XID */
master-bin.000001 # Table_map # # table_id: # (test.t)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Xid # # COMMIT /* XID */

slave-bin.000001 # Query # # BEGIN
slave-bin.000001 # Table_map # # table_id: # (test.t)
slave-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
slave-bin.000001 # Query # # SAVEPOINT `savepoint_1`
slave-bin.000001 # Xid # # COMMIT /* XID */
slave-bin.000001 # Query # # BEGIN
slave-bin.000001 # Table_map # # table_id: # (test.t)
slave-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
slave-bin.000001 # Xid # # COMMIT /* XID */

There are two issues in master binary log:

1) The absence of STMT_END_F
2) The absence of "COMMIT"

#### 1) The absence of STMT_END_F

Consider the first issue. The question is why slave binary log has STMT_END_F?

See Query_log_event::do_apply_event(). It closes thread tables and finalizes previous statements before new event applying.

#0 binlog_cache_data::set_pending (this=0x7fffbc00de70, pending=0x0)
    at ./sql/binlog.cc:367
#1 0x0000000000a3e276 in MYSQL_BIN_LOG::flush_and_set_pending_rows_event (
    this=0x185cdc0 <mysql_bin_log>, thd=0x7fffbc000a40, event=0x0,
    is_transactional=true)
    at ./sql/binlog.cc:5412
#2 0x0000000000a469af in THD::binlog_flush_pending_rows_event (
    this=0x7fffbc000a40, stmt_end=true, is_transactional=true)
    at ./sql/binlog.cc:9088
#3 0x0000000000775bd7 in THD::binlog_flush_pending_rows_event (
    this=0x7fffbc000a40, stmt_end=true)
    at ./sql/sql_class.h:2537
#4 0x0000000000763155 in close_thread_tables (thd=0x7fffbc000a40)
    at ./sql/sql_base.cc:1455
#5 0x0000000000a7c3a5 in Relay_log_info::slave_close_thread_tables (
    this=0x1bb2140, thd=0x7fffbc000a40)
    at ./sql/rpl_rli.cc:1607
#6 0x0000000000a0f54d in Query_log_event::do_apply_event (
    this=0x7fffbc05ad50, rli=0x1bb2140,
    query_arg=0x7fffbc05aad9 "SAVEPOINT `savepoint_1`", q_len_arg=23)
    at ./sql/log_event.cc:4731
#7 0x0000000000a0f05f in Query_log_event::do_apply_event (
    this=0x7fffbc05ad50, rli=0x1bb2140)
    at ./sql/log_event.cc:4585

How to fix?

Actually there is no need to fix it. Here is the comment in MYSQL_BIN_LOG::write_event() function:

/*
    We only end the statement if we are in a top-level statement. If
    we are inside a stored function, we do not end the statement since
    this will close all tables on the slave.
  */

So STMT_END_F flag absence in event before SAVEPOINT in trigger or SP is a correct behavior for master. From slave's point of view STMT_END_F flag presence is correct too because there is no trigger or SP call in slave thread. There is just events applying.

#### 2) The absence of "COMMIT"

Consider the second issue.

If we add new event between SAVEPOINT and the end of trigger body then we will see the following binlog:

--delimiter |
CREATE TRIGGER t_insert_trig AFTER INSERT ON t
 FOR EACH ROW
  BEGIN

    SAVEPOINT savepoint_1;

      INSERT INTO `t2` VALUES (NEW.f1);

  END |
--delimiter ;

INSERT INTO `t` VALUES (2);
INSERT INTO `t` VALUES (3);

master-bin.000001 # Query # # BEGIN
master-bin.000001 # Table_map # # table_id: # (test.t)
master-bin.000001 # Table_map # # table_id: # (test.t2)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Query # # SAVEPOINT `savepoint_1`
master-bin.000001 # Table_map # # table_id: # (test.t)
master-bin.000001 # Table_map # # table_id: # (test.t2)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Xid # # COMMIT /* XID */
master-bin.000001 # Query # # BEGIN
master-bin.000001 # Table_map # # table_id: # (test.t)
master-bin.000001 # Table_map # # table_id: # (test.t2)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Query # # SAVEPOINT `savepoint_1`
master-bin.000001 # Table_map # # table_id: # (test.t)
master-bin.000001 # Table_map # # table_id: # (test.t2)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Xid # # COMMIT /* XID */

slave-bin.000001 # Query # # BEGIN
slave-bin.000001 # Table_map # # table_id: # (test.t2)
slave-bin.000001 # Table_map # # table_id: # (test.t)
slave-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
slave-bin.000001 # Query # # SAVEPOINT `savepoint_1`
slave-bin.000001 # Table_map # # table_id: # (test.t2)
slave-bin.000001 # Table_map # # table_id: # (test.t)
slave-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
slave-bin.000001 # Xid # # COMMIT /* XID */
slave-bin.000001 # Query # # BEGIN
slave-bin.000001 # Table_map # # table_id: # (test.t2)
slave-bin.000001 # Table_map # # table_id: # (test.t)
slave-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
slave-bin.000001 # Query # # SAVEPOINT `savepoint_1`
slave-bin.000001 # Table_map # # table_id: # (test.t2)
slave-bin.000001 # Table_map # # table_id: # (test.t)
slave-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
slave-bin.000001 # Xid # # COMMIT /* XID */

The questions is why we have "COMMIT" in this case?

It's because write_locked_table_maps() invokes binlog_start_trans_and_stmt() for "INSERT INTO `t` VALUES (3);".

(gdb) bt
#0 binlog_start_trans_and_stmt (thd=0x1cbd4e0, start_event=0x7ffff0299330)
    at ./sql/binlog.cc:7729
#1 0x0000000000a440aa in THD::binlog_write_table_map (this=0x1cbd4e0,
    table=0x7fffa404ae30, is_transactional=true, binlog_rows_query=false)
    at ./sql/binlog.cc:7805
#2 0x0000000000645147 in write_locked_table_maps (thd=0x1cbd4e0, force=false)
    at ./sql/handler.cc:7503
#3 0x0000000000645242 in binlog_log_row (table=0x7fffa404ae30,
    before_record=0x0, after_record=0x7fffa404c340 "\377\003",
    log_func=0x64994c <Write_rows_log_event::binlog_row_logging_function(THD*, TABLE*, bool, unsigned char const*, unsigned char const*)>)
    at ./sql/handler.cc:7543
#4 0x0000000000645852 in handler::ha_write_row (this=0x7fffa404d2c0,
    buf=0x7fffa404c340 "\377\003")
    at ./sql/handler.cc:7693
#5 0x00000000007b9006 in write_record (thd=0x1cbd4e0, table=0x7fffa404ae30,
    info=0x7ffff02998b0, update=0x7ffff0299930)
    at ./sql/sql_insert.cc:1947
#6 0x00000000007b6d1e in mysql_insert (thd=0x1cbd4e0,
    table_list=0x7fffa4004d40, fields=..., values_list=..., update_fields=...,
    update_values=..., duplic=DUP_ERROR, ignore=false)
    at ./sql/sql_insert.cc:1085
#7 0x00000000007d87de in mysql_execute_command (thd=0x1cbd4e0)
    at ./sql/sql_parse.cc:3892
#8 0x00000000007e0af8 in mysql_parse (thd=0x1cbd4e0,
    rawbuf=0x7fffa4004c50 "INSERT INTO `t` VALUES (3)", length=26,
    parser_state=0x7ffff029b1b0)
    at ./sql/sql_parse.cc:6958
#9 0x00000000007d2a70 in dispatch_command (command=COM_QUERY, thd=0x1cbd4e0,
    packet=0x1cc0c61 "INSERT INTO `t` VALUES (3)", packet_length=26)
    at ./sql/sql_parse.cc:1442
#10 0x00000000007d1925 in do_command (thd=0x1cbd4e0)
    at ./sql/sql_parse.cc:1054
#11 0x000000000079b0ff in do_handle_one_connection (thd_arg=0x1cbd4e0)
    at ./sql/sql_connect.cc:1541
#12 0x000000000079ab87 in handle_one_connection (arg=0x1cbd4e0)
    at ./sql/sql_connect.cc:1444
#13 0x0000000000da33ce in pfs_spawn_thread (arg=0x1c3db40)
    at ./storage/perfschema/pfs.cc:1860
#14 0x00007ffff737d182 in start_thread (arg=0x7ffff029c700)
    at pthread_create.c:312
#15 0x00007ffff688a47d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Why binlog_start_trans_and_stmt() is not invoked if there is nothing between SAVEPOINT and trigger body end?

It's because the number of tables in binary log table map is not zero:

(gdb) bt
#0 write_locked_table_maps (thd=0x1cbbfd0, force=false)
    at ./sql/handler.cc:7458
#1 0x0000000000645242 in binlog_log_row (table=0x7fffb004ae30,
    before_record=0x0, after_record=0x7fffb004d2b0 "\377\003",
    log_func=0x64994c <Write_rows_log_event::binlog_row_logging_function(THD*, TABLE*, bool, unsigned char const*, unsigned char const*)>)
    at ./sql/handler.cc:7543
#2 0x0000000000645852 in handler::ha_write_row (this=0x7fffb004e7c0,
    buf=0x7fffb004d2b0 "\377\003")
    at ./sql/handler.cc:7693
#3 0x00000000007b9006 in write_record (thd=0x1cbbfd0, table=0x7fffb004ae30,
    info=0x7ffff02998b0, update=0x7ffff0299930)
    at ./sql/sql_insert.cc:1947
#4 0x00000000007b6d1e in mysql_insert (thd=0x1cbbfd0,
    table_list=0x7fffb0004d40, fields=..., values_list=..., update_fields=...,
    update_values=..., duplic=DUP_ERROR, ignore=false)
    at ./sql/sql_insert.cc:1085
#5 0x00000000007d87de in mysql_execute_command (thd=0x1cbbfd0)
    at ./sql/sql_parse.cc:3892
#6 0x00000000007e0af8 in mysql_parse (thd=0x1cbbfd0,
    rawbuf=0x7fffb0004c50 "INSERT INTO `t` VALUES (3)", length=26,
    parser_state=0x7ffff029b1b0)
    at ./sql/sql_parse.cc:6958
---Type <return> to continue, or q <return> to quit---
#7 0x00000000007d2a70 in dispatch_command (command=COM_QUERY, thd=0x1cbbfd0,
    packet=0x1cbf751 "INSERT INTO `t` VALUES (3)", packet_length=26)
    at ./sql/sql_parse.cc:1442
#8 0x00000000007d1925 in do_command (thd=0x1cbbfd0)
    at ./sql/sql_parse.cc:1054
#9 0x000000000079b0ff in do_handle_one_connection (thd_arg=0x1cbbfd0)
    at ./sql/sql_connect.cc:1541
#10 0x000000000079ab87 in handle_one_connection (arg=0x1cbbfd0)
    at ./sql/sql_connect.cc:1444
#11 0x0000000000da33ce in pfs_spawn_thread (arg=0x1c30f00)
    at ./storage/perfschema/pfs.cc:1860
#12 0x00007ffff737d182 in start_thread (arg=0x7ffff029c700)
    at pthread_create.c:312
#13 0x00007ffff688a47d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) n
7459 DBUG_PRINT("enter", ("thd: 0x%lx thd->lock: 0x%lx "
(gdb)
7463 DBUG_PRINT("debug", ("get_binlog_table_maps(): %d", thd->get_binlog_table_maps()));
(gdb)
7465 if (force || (thd->get_binlog_table_maps() == 0))
(gdb)
7518 DBUG_RETURN(0);
(gdb) p force
$1 = false
(gdb) p thd->get_binlog_table_maps()
$2 = 1

How is this number zeroed out for the case if there is some event between SAVEPOINT and trigger body end?

(gdb) bt
#0 THD::clear_binlog_table_maps (this=0x1cbcd80)
    at ./sql/sql_class.h:2659
#1 0x0000000000a4908a in binlog_cache_data::flush_pending_event (
    this=0x7fffa40088e0, thd=0x1cbcd80)
    at ./sql/binlog.cc:499
#2 0x0000000000a33d57 in binlog_cache_data::finalize (this=0x7fffa40088e0,
    thd=0x1cbcd80, end_event=0x7ffff02986b0)
    at ./sql/binlog.cc:1207
#3 0x0000000000a41c2b in MYSQL_BIN_LOG::commit (
    this=0x185cdc0 <mysql_bin_log>, thd=0x1cbcd80, all=false)
    at ./sql/binlog.cc:6675
#4 0x0000000000638429 in ha_commit_trans (thd=0x1cbcd80, all=false,
    ignore_global_read_lock=false)
    at ./sql/handler.cc:1513
#5 0x00000000008ab4ee in trans_commit_stmt (thd=0x1cbcd80)
    at ./sql/transaction.cc:436
#6 0x00000000007dd7c5 in mysql_execute_command (thd=0x1cbcd80)
    at ./sql/sql_parse.cc:5576
#7 0x00000000007e0af8 in mysql_parse (thd=0x1cbcd80,
    rawbuf=0x7fffa4004c50 "INSERT INTO `t` VALUES (2)", length=26,
    parser_state=0x7ffff029b1b0)
    at ./sql/sql_parse.cc:6958
#8 0x00000000007d2a70 in dispatch_command (command=COM_QUERY, thd=0x1cbcd80,
---Type <return> to continue, or q <return> to quit---
    packet=0x1cc0501 "INSERT INTO `t` VALUES (2)", packet_length=26)
    at ./sql/sql_parse.cc:1442
#9 0x00000000007d1925 in do_command (thd=0x1cbcd80)
    at ./sql/sql_parse.cc:1054
#10 0x000000000079b0ff in do_handle_one_connection (thd_arg=0x1cbcd80)
    at ./sql/sql_connect.cc:1541
#11 0x000000000079ab87 in handle_one_connection (arg=0x1cbcd80)
    at ./sql/sql_connect.cc:1444
#12 0x0000000000da33ce in pfs_spawn_thread (arg=0x1c67750)
    at ./storage/perfschema/pfs.cc:1860
#13 0x00007ffff737d182 in start_thread (arg=0x7ffff029c700)
    at pthread_create.c:312
#14 0x00007ffff688a47d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

So we have the situation when binlog_cache_data::m_pending is flushed on 'SAVEPOINT' execution but THD::binlog_table_maps is not cleared. How is this possible? There is binlog_cache_data::set_pending() function which does not change THD::binlog_table_maps. Non-zeroed THD::binlog_table_maps is the reason why binlog_start_trans_and_stmt() is not invoked from write_locked_table_maps() for "INSERT INTO `t` VALUES (3);".

How to fix?

binlog_cache_data::m_pending can be changed with the following call stacks:

1)
binlog_cache_data::set_pending()
MYSQL_BIN_LOG::flush_and_set_pending_rows_event()
THD::binlog_flush_pending_rows_event()
MYSQL_BIN_LOG::write_event()
binlog_cache_data::flush_pending_event()

2)
binlog_cache_data::set_pending()
MYSQL_BIN_LOG::flush_and_set_pending_rows_event()
THD::binlog_flush_pending_rows_event()
MYSQL_BIN_LOG::write_event()
binlog_savepoint_set()
ha_savepoint()

The difference between this two ways is that binlog_cache_data::flush_pending_event() invokes THD::clear_binlog_table_maps() but binlog_savepoint_set() does not do this.

So the fix is in invoking THD::clear_binlog_table_maps() in binlog_savepoint_set() just after MYSQL_BIN_LOG::write_event() call.

Note: this fix will also fix this bug https://bugs.launchpad.net/percona-server/+bug/1438990 .

This can be explained so that THD::binlog_table_maps is cleared during savepoint setup and the next write_locked_table_maps() call will write table maps as THD::binlog_table_maps is zero.

(gdb) bt
#0 write_locked_table_maps (thd=0x1ca4810, force=false)
    at ./sql/handler.cc:7458
#1 0x00000000006451e0 in binlog_log_row (table=0x7fffac046740,
    before_record=0x0, after_record=0x7fffac050900 "\377\003",
    log_func=0x6498c9 <Write_rows_log_event::binlog_row_logging_function(THD*, TABLE*, bool, unsigned char const*, unsigned char const*)>)
    at ./sql/handler.cc:7543
#2 0x00000000006457f0 in handler::ha_write_row (this=0x7fffac052d80,
    buf=0x7fffac050900 "\377\003")
    at ./sql/handler.cc:7693
#3 0x00000000007b8fa2 in write_record (thd=0x1ca4810, table=0x7fffac046740,
    info=0x7ffff035c8b0, update=0x7ffff035c930)
    at ./sql/sql_insert.cc:1947
#4 0x00000000007b6cba in mysql_insert (thd=0x1ca4810,
    table_list=0x7fffac004d40, fields=..., values_list=..., update_fields=...,
    update_values=..., duplic=DUP_ERROR, ignore=false)
    at ./sql/sql_insert.cc:1085
#5 0x00000000007d877a in mysql_execute_command (thd=0x1ca4810)
    at ./sql/sql_parse.cc:3892
#6 0x00000000007e0a94 in mysql_parse (thd=0x1ca4810,
    rawbuf=0x7fffac004c50 "INSERT INTO `t` VALUES (3)", length=26,
    parser_state=0x7ffff035e1b0)
    at ./sql/sql_parse.cc:6958
---Type <return> to continue, or q <return> to quit---
#7 0x00000000007d2a0c in dispatch_command (command=COM_QUERY, thd=0x1ca4810,
    packet=0x1ca89c1 "INSERT INTO `t` VALUES (3)", packet_length=26)
    at ./sql/sql_parse.cc:1442
#8 0x00000000007d18c1 in do_command (thd=0x1ca4810)
    at ./sql/sql_parse.cc:1054
#9 0x000000000079b09b in do_handle_one_connection (thd_arg=0x1ca4810)
    at ./sql/sql_connect.cc:1541
#10 0x000000000079ab23 in handle_one_connection (arg=0x1ca4810)
    at ./sql/sql_connect.cc:1444
#11 0x0000000000da336a in pfs_spawn_thread (arg=0x1c17170)
    at ./storage/perfschema/pfs.cc:1860
#12 0x00007ffff737d182 in start_thread (arg=0x7ffff035f700)
    at pthread_create.c:312
#13 0x00007ffff688a47d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Note: This will also fix this bug https://bugs.launchpad.net/percona-server/+bug/1464468 (see explanation here: https://bugs.launchpad.net/percona-server/+bug/1464468/comments/2 )

Tags: i51914
Vlad Lesin (vlad-lesin)
Changed in percona-server:
assignee: nobody → Vlad Lesin (vlad-lesin)
Vlad Lesin (vlad-lesin)
description: updated
tags: added: i51914
Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :
Download full text (5.8 KiB)

I see the following output from the test case on upstream 5.6.27:

openxs@ao756:~/dbs/5.6/mysql-test$ cat suite/rpl/t/bug1483251.test
--source include/have_binlog_format_row.inc
--source include/master-slave.inc

CREATE TABLE `t` (
`f1` int(10) unsigned NOT NULL,
PRIMARY KEY (`f1`)
) ENGINE=InnoDB;

--delimiter |
CREATE TRIGGER t_insert_trig AFTER INSERT ON t
    FOR EACH ROW
        BEGIN
                    SAVEPOINT savepoint_1;
                    SET @a = 10;
        END |
--delimiter ;

INSERT INTO t VALUES (2);
INSERT INTO t VALUES (3);

--source include/show_binlog_events.inc

SELECT * FROM t;

--source include/sync_slave_sql_with_master.inc

--connection slave
SELECT * FROM t;
--source include/show_binlog_events.inc

--connection master
DROP TABLE t;

--source include/rpl_end.inc

openxs@ao756:~/dbs/5.6/mysql-test$ ./mtr --suite=rpl bug1483251
Logging: ./mtr --suite=rpl bug1483251
2015-11-17 09:55:23 0 [Note] /home/openxs/dbs/5.6/bin/mysqld (mysqld 5.6.27) starting as process 25121 ...
2015-11-17 09:55:23 25121 [Warning] Buffered warning: Changed limits: max_open_files: 1024 (requested 5000)

2015-11-17 09:55:23 25121 [Warning] Buffered warning: Changed limits: table_open_cache: 431 (requested 2000)

2015-11-17 09:55:23 25121 [Note] Plugin 'FEDERATED' is disabled.
2015-11-17 09:55:23 25121 [Note] Binlog end
2015-11-17 09:55:23 25121 [Note] Shutting down plugin 'CSV'
2015-11-17 09:55:23 25121 [Note] Shutting down plugin 'MyISAM'
MySQL Version 5.6.27
Checking supported features...
 - SSL connections supported
Collecting tests...
 - adding combinations for rpl
Checking leftover processes...
Removing old var directory...
Creating var directory '/home/openxs/dbs/5.6/mysql-test/var'...
Installing system database...

==============================================================================

TEST RESULT TIME (ms) or COMMENT
--------------------------------------------------------------------------

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009
rpl.bug1483251 'mix' [ skipped ] Doesn't support --binlog-format='mixed'
rpl.bug1483251 'row' [ fail ]
        Test ended at 2015-11-17 09:55:37

CURRENT_TEST: rpl.bug1483251
--- /home/openxs/dbs/5.6/mysql-test/suite/rpl/r/bug1483251.result 2015-11-17 10:48:36.487992561 +0300
+++ /home/openxs/dbs/5.6/mysql-test/var/log/bug1483251.reject 2015-11-17 10:55:37.663973783 +0300
@@ -0,0 +1,72 @@
+include/master-slave.inc
+Warnings:
+Note #### Sending passwords in plain text without SSL/TLS is extremely insecure.
+Note #### Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
+[connection master]
+CREATE TABLE `t` (
+`f1` int(10) unsigned NOT NULL,
+PRIMARY KEY (`f1`)
+) ENGINE=InnoDB;
+CREATE TRIGGER t_insert_trig AFTER INSERT ON t
+FOR EACH ROW
+BEGIN
+SAVEPOINT savepoint_1;
+SET @a = 10;
+END |
+INSERT INTO t VALUES (2);
+INSERT INTO t VALUES (3);
+include/show...

Read more...

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

Vlad, is this fixed now?

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-918

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.