Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 13.1, 12.3.3
-
None
-
Linux x86_64, MariaDB.org Ubuntu 24.04 binary distribution
Description
Calling sys.ps_setup_reload_saved() without first calling sys.ps_setup_save() correctly raises error 1644, but it also changes the calling session's sql_log_bin value from 1 to 0. The session setting remains changed after the procedure returns the error.
This occurs when sys.ps_setup_reload_saved() is called without a preceding sys.ps_setup_save(), causing its error path to change the session's sql_log_bin setting.
I reproduced this on MariaDB 12.3.3. Run the following script in one administrative MariaDB client session:
DROP DATABASE IF EXISTS reload_test; |
CREATE DATABASE reload_test; |
USE reload_test; |
|
|
DELIMITER //
|
CREATE PROCEDURE call_reload() |
BEGIN
|
DECLARE v_error BOOL DEFAULT FALSE; |
DECLARE v_errno INT DEFAULT 0; |
DECLARE v_message TEXT DEFAULT ''; |
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION |
BEGIN |
SET v_error=TRUE; |
GET DIAGNOSTICS CONDITION 1
|
v_errno=MYSQL_ERRNO, v_message=MESSAGE_TEXT;
|
END; |
|
|
CALL sys.ps_setup_reload_saved();
|
SELECT 'call_result' AS marker, v_error AS call_failed, |
v_errno AS error_number, v_message AS error_message; |
END// |
DELIMITER ;
|
|
|
SET @before_log_bin := @@session.sql_log_bin; |
SELECT 'before' AS marker, @before_log_bin AS sql_log_bin; |
CALL call_reload();
|
SELECT 'state_after_call' AS marker, |
@@session.sql_log_bin AS sql_log_bin_after_error, |
(@@session.sql_log_bin = @before_log_bin) AS restored; |
|
|
SET SESSION sql_log_bin=@before_log_bin; |
DO RELEASE_LOCK('sys.ps_setup_save'); |
DROP DATABASE reload_test; |
The recorded result was:
marker sql_log_bin
|
before 1
|
marker call_failed error_number error_message
|
call_result 1 1644 An error occurred, was sys.ps_setup_save() run before this procedure?
|
marker sql_log_bin_after_error restored
|
state_after_call 0 0
|
The call is intentionally expected to fail because no saved setup exists. That failure should not alter unrelated session state: sql_log_bin_after_error should remain equal to its captured value and restored should be 1. Instead, the procedure leaves binary logging disabled for subsequent statements in the same session. The final statements restore the original value and release the named lock defensively.