<p>MySQL raises error 1639 (ER_DEBUG_SYNC_TIMEOUT) when a session waits too long at a DEBUG_SYNC synchronization point.</p>
<p>MySQL Error 1639: ER_DEBUG_SYNC_TIMEOUT appears when a DEBUG_SYNC wait exceeds its timeout, usually during concurrency debugging. Remove or shorten the wait, increase the timeout, or disable DEBUG_SYNC to fix the issue.</p>
debug sync point wait timed out
Error 1639 with SQLSTATE HY000 is triggered by MySQLs internal DEBUG_SYNC facility when a session reaches a sync point but the expected signal does not arrive within the specified timeout period. The server aborts the wait and throws the message "debug sync point wait timed out".
This error only occurs when DEBUG_SYNC is enabled, typically in development or automated testing environments where precise thread ordering is required. Production systems rarely enable DEBUG_SYNC, so the error is uncommon outside test harnesses.
The primary cause is a mismatch between WAIT_FOR and SIGNAL statements in DEBUG_SYNC. When a thread issues WAIT_FOR 'point' TIMEOUT n and no other thread issues SIGNAL 'point', the timeout expires.
Using an overly short timeout, disabling the signaling thread, or connection loss can also leave the waiting thread stranded, producing the error. Server restarts during the wait will always trigger the timeout as well.
The quickest fix is to ensure every WAIT_FOR has a matching SIGNAL with sufficient time. Verify your test script or stored procedure sends the expected SIGNAL before the timeout.
If timing is unpredictable, raise the timeout value or remove the WAIT_FOR entirely. Disabling DEBUG_SYNC by running SET GLOBAL debug_sync = 'OFF'; will prevent the error but removes sync-point testing.
In parallel replication tests, workers may hit WAIT_FOR 'after_commit' TIMEOUT 3. Increase TIMEOUT to 30 or add SIGNAL 'after_commit' in the coordinator thread.
During deadlock simulation, a canceled client may never reach its SIGNAL. Add error handling that triggers SIGNAL in an ensure/FINALLY block to guarantee cleanup.
Always pair WAIT_FOR with SIGNAL in the same test case. Document every debug sync point so future maintainers do not remove the matching code.
Use generous timeouts during CI to accommodate slower runners. Reset debug_sync to OFF in production builds to eliminate accidental waits.
Error 1638 ER_DEBUG_SYNC_HIT occurs when a sync point is reached and can precede error 1639 if the wait is misconfigured. Fixing the pairing logic resolves both. Error ER_SERVER_SHUTDOWN may follow if the server exits while waiting; handle shutdown events gracefully.
A WAIT_FOR statement has no matching SIGNAL, so the session waits until the timeout expires.
The SIGNAL arrives, but heavy load delays it beyond the short timeout value configured in WAIT_FOR.
The thread responsible for SIGNAL terminates unexpectedly, leaving the waiter stranded.
Accidentally leaving DEBUG_SYNC enabled after testing can expose edge cases and timeouts under real load.
Indicates a sync point was reached; often appears just before 1639 if WAIT_FOR is misused.
Raised when the server shuts down, which can interrupt a DEBUG_SYNC wait and produce cascading failures.
Though unrelated to DEBUG_SYNC, both errors involve waiting too long; understanding lock waits helps distinguish root causes.
Only if debug_sync is ON. Standard builds ship with it OFF, so production servers should never throw this error.
Start the server with --debug-sync-timeout=0 or add SET GLOBAL debug_sync='OFF' in your init script.
No, the timeout only applies when a thread is already waiting. Normal execution is unaffected.
Galaxy flags SET debug_sync statements in reviews, reminding teams to turn them off before merging code, reducing the chance of runtime timeouts.
.avif)
.avif){kind=logo}
