mariadb/mysql-test/r/federated_debug.result
Davi Arnaut d941a1f304 Bug#47525: MySQL crashed (Federated)
On Mac OS X or Windows, sending a SIGHUP to the server or a
asynchronous flush (triggered by flush_time), would cause the
server to crash.

The problem was that a hook used to detach client API handles
wasn't prepared to handle cases where the thread does not have
a associated session.

The solution is to verify whether the thread has a associated
session before trying to detach a handle.
2009-09-30 18:38:02 -03:00

37 lines
880 B
Text

stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
stop slave;
DROP DATABASE IF EXISTS federated;
CREATE DATABASE federated;
DROP DATABASE IF EXISTS federated;
CREATE DATABASE federated;
#
# Bug#47525: MySQL crashed (Federated)
#
# Switch to slave
CREATE TABLE t1(a INT);
INSERT INTO t1 VALUES (1);
# Switch to master
CREATE TABLE t1(a INT) ENGINE=FEDERATED
CONNECTION='mysql://root@127.0.0.1:SLAVE_PORT/test/t1';
SELECT * FROM t1;
a
1
# Start a asynchronous reload
# Wait for tables to be closed
# Ensure that the server didn't crash
SELECT * FROM t1;
a
1
# Drop tables on master and slave
DROP TABLE t1;
DROP TABLE t1;
# Federated cleanup
DROP TABLE IF EXISTS federated.t1;
DROP DATABASE IF EXISTS federated;
DROP TABLE IF EXISTS federated.t1;
DROP DATABASE IF EXISTS federated;