The session still owns a GTID and therefore cannot change certain system variables until it commits or rolls back.
MySQL error 3138 (ER_CANT_SET_VARIABLE_WHEN_OWNING_GTID) appears when a transaction that still owns a GTID tries to modify a protected variable. Finish the transaction with COMMIT or ROLLBACK to release the GTID, then set the variable.
ER_CANT_SET_VARIABLE_WHEN_OWNING_GTID
MySQL raises error 3138 when a client that still owns a Global Transaction Identifier (GTID) attempts to change a system variable that requires no active GTID ownership. The server blocks the change to protect transactional consistency.
The error message explicitly names the variable you tried to change and the GTID currently owned. Ownership ends automatically once the transaction is completed with COMMIT or ROLLBACK.
The error surfaces inside explicit transactions, XA transactions, or stored procedures that started a GTID but have not yet been committed. Any SET statement targeting restricted variables such as autocommit, gtid_next, or session sql_log_bin can trigger it while the GTID is active.
It first appeared in MySQL 5.7.8 alongside enhanced GTID protections and remains unchanged in MySQL 8.x.
Leaving transactions open prevents other sessions from accessing updated rows, increases lock contention, and slows replication. Quickly completing or rolling back the transaction restores normal performance and allows variable changes.
Attempting to SET autocommit=1 while a GTID transaction is still open will immediately raise 3138.
Running SET SESSION sql_log_bin=0 inside a long-running transaction that owns a GTID also triggers the error.
In replication environments, issuing SET gtid_next without first committing the previous GTID makes the server return 3138.
The fastest fix is to finish the transaction so the server releases the GTID. Once released, the variable may be changed without error.
If the change must happen inside a transaction, redesign the code to set the variable before BEGIN or after COMMIT.
1. Identify the session variable you attempted to set. 2. Issue COMMIT or ROLLBACK. 3. Re-execute the SET statement. 4. Verify with SELECT @@autocommit or similar.
Autocommit toggling inside migration scripts often triggers 3138. Commit after each DML block to avoid the error.
Mixed-format replication setups sometimes disable sql_log_bin mid-transaction. Move that command outside the transaction boundary.
Always close explicit transactions promptly. Use shorter transactions to reduce GTID ownership time.
Structure code so that session-scope SET statements appear before BEGIN or after COMMIT. Enforce this rule in code reviews.
Galaxy's SQL editor highlights long-running transactions and shows current GTID ownership in the sidebar. You can commit or roll back with one click, then safely apply configuration changes.
Error 1782 (ER_GTID_MODE_READ_ONLY) indicates GTID mode is read-only and must be toggled in my.cnf, not at runtime.
Error 1780 (ER_VARIABLE_IS_READONLY) occurs when trying to change a read-only variable regardless of GTID status.
SET autocommit requires no active GTID ownership. Executing it mid-transaction raises 3138.
The server forbids changing gtid_next until the current GTID is released.
SET SESSION sql_log_bin=0 inside a GTID transaction triggers the error because replication safety could be compromised.
Occurs when attempting to modify GTID_MODE at runtime while read-only restrictions are active.
Raised when attempting to set a variable marked as read-only regardless of GTID status.
Happens when gtid_purged is set while GTID_MODE is OFF.
No data is lost. The server only blocks a variable change until the GTID is released.
Disabling GTIDs removes the protection but also forfeits replication guarantees. Commit instead.
No. The restriction is hard-coded to protect transactional integrity.
Galaxy surfaces active GTID sessions in its status bar and highlights attempted variable changes that would fail.
.avif)
.avif){kind=logo}
