| Bug #43992 | slave sql thread can't tune own sql_mode via @@global.sql_mode | ||
|---|---|---|---|
| Submitted: | 31 Mar 2009 17:43 | ||
| Reporter: | Andrei Elkin | Email Updates: | |
| Status: | Verified | ||
| Category: | Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.0+ | OS: | Any |
| Assigned to: | Andrei Elkin | Target Version: | |
| Triage: | Triaged: D3 (Medium) | ||
© 2010, Oracle Corporation and/or its affiliates.
Portions of this website are copyright © 2001, 2002 The PHP Group.
Page generated in 0.039 sec. using MySQL 5.5.16-enterprise-commercial-advanced-log
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.
Description: Although sql_mode for the SQL thread is inherited from the @@global it might change at handling of some of event irrecoverably. Consider e.g: Query_log_event::do_apply_event() if (sql_mode_inited) thd->variables.sql_mode= (ulong) ((thd->variables.sql_mode & MODE_NO_DIR_IN_CREATE) | (sql_mode & ~(ulong) MODE_NO_DIR_IN_CREATE)); In effect of executing of the pasted code, the slave sql thread looses the former @@session that might have set on purpose to some sensible value (e.g bug#38173 needs it to control reaction on lack of the default value for a field). How to repeat: look into source code; gdb with br point at the forementioned code. Suggested fix: To make sure that sql_mode is restored each time an event handler needs to change it from the initial value.