Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
11.8.3
-
None
-
Debian 13
Description
Summary
While running a large restore with myloader, sql_errors.log contains corrupted/concatenated entries. A new log entry may begin in the middle of the SQL text of the previous entry, so the
logged statement is no longer a faithful representation of the original failing SQL.
This makes the error log unreliable for diagnostics and breaks automated parsing.
Description
We observed that sql_errors.log* sometimes stores multiple SQL error entries without a clean separation. In some cases, the prefix of a new log entry:
YYYY-MM-DD HH:MM:SS user[user] @ host [db] ERROR ...
appears inside the SQL text of the previous logged statement.
This is especially visible with very large INSERT INTO ... VALUES (...) statements containing large JSON or text payloads.
As a result:
- the SQL recorded in the log becomes syntactically invalid
- one logged statement may contain part of the next error entry
- the log can no longer be trusted as a faithful record of the original failing query
- automated analysis/parsing becomes unreliable
Observed Example
Real example seen in sql_errors.log*:
2026-03-18 18:22:31 root[root] @ localhost [] WARNING 1265: Data truncated for column 'dp_nb_stopover' at row 1367 : /* Completed: 80% */ INSERT INTO `prestation` VALUES(15231970,NULL,NU LL,NULL,NULL,NULL,"300525-hotel_mont-5N-DP-2-travelfusion","",0,0,0,NULL,NULL,"stay",NULL,"pax",0,0,0,1,1,0,0,NULL,"illimited","daily","published",6,NULL,NULL,"none","TransportDP",NULL," pax",NULL,NULL,NULL,NULL,NULL,NULL,NULL,15231968,787,1478,NULL,NULL,1478,787,NULL,NULL,1,NULL,"","travelfusion","LCC","ECO","0",NULL,NULL,NULL,NULL,"round",1,NULL,1,NULL,0,0,NULL,0,NULL, 0,1,_binary "2025-05-30 15:02:23",_binary "2025-05-30 15:02:23",1,NULL,NULL,NULL),(15231971,NULL,NULL,NULL,NULL,NULL,"300525-hotel_mont-5N-DP-2-travelport","",0,0,0,NULL,NULL,"stay",NULL ,"pax",0,0,0,1,1,0,0,NULL,"illimited","daily","published",6,NULL,NULL,"none","TransportDP",NULL,"pax",NULL,NULL,NULL,NULL,NULL,NULL,NULL,15231968,787,1478,NULL,NULL,1478,787,NULL,NULL,1, NULL,"","travelport","LCC","ECO","0",NULL,NULL,NULL,NULL,"round",1,NULL,1,NULL,0,0,NULL,0,NUL2026-03-18 18:22:31 root[root] @ localhost [] WARNING 1265: Data truncated for column 'dp_typ e_cabine' at row 1372 : /* Completed: 80% */ INSERT INTO `prestation` VALUES(15231970,NULL,NULL,NULL,NULL,NULL,"300525-hotel_mont-5N-DP-2-travelfusion","",0,0,0,NULL,NULL,"stay",NULL,"pa x",0,0,0,1,1,0,0,NULL,"illimited","daily","published",6,NULL,NULL,"none","TransportDP",NULL,"pax",NULL,NULL,NULL,NULL,NULL,NULL,NULL,15231968,787,1478,NULL,NULL,1478,787,NULL,NULL,1,NULL ,"","travelfusion","LCC","ECO","0",NULL,NULL,NULL,NULL,"round",1,NULL,1,NULL,0,0,NULL,0,NULL,0,1,_binary "2025-05-30 15:02:23",_binary "2025-05-30 15:02:23",1,NULL,NULL,NULL),(15231971,N ULL,NULL,NULL,NULL,NULL,"300525-hotel_mont-5N-DP-2-travelport","",0,0,0,NULL,NULL,"stay",NULL,"pax",0,0,0,1,1,0,0,NULL,"illimited","daily","published",6,NULL,NULL,"none","TransportDP",NU LL,"pax",NULL,NULL,NULL,NULL,NULL,NULL,NULL,15231968,787,1478,NULL,NULL,1478,787,NULL,NULL,1,NULL,"","travelport","LCC","ECO","0",NULL,NULL,NULL,NULL,"round",1,NULL,1,NULL,0,0,NULL,0,NUL 2026-03-18 18:22:31 root[root] @ localhost [] WARNING 1265: Data truncated for column 'dp_nb_stopover' at row 1372 : /* Completed: 80% */ INSERT INTO `prestation` VALUES(15231970,NULL,NU LL,NULL,NULL,NULL,"300525-hotel_mont-5N-DP-2-travelfusion","",0,0,0,NULL,NULL,"stay",NULL,"pax",0,0,0,1,1,0,0,NULL,"illimited","daily","published",6,NULL,NULL,"none","TransportDP",NULL," pax",NULL,NULL,NULL,NULL,NULL,NULL,NULL,15231968,787,1478,NULL,NULL,1478,787,NULL,NULL,1,NULL,"","travelfusion","LCC","ECO","0",NULL,NULL,NULL,NULL,"round",1,NULL,1,NULL,0,0,NULL,0,NULL, 0,1,_binary "2025-05-30 15:02:23",_binary "2025-05-30 15:02:23",1,NULL,NULL,NULL),(15231971,NULL,NULL,NULL,NULL,NULL,"300525-hotel_mont-5N-DP-2-travelport","",0,0,0,NULL,NULL,"stay",NULL ,"pax",0,0,0,1,1,0,0,NULL,"illimited","daily","published",6,NULL,NULL,"none","TransportDP",NULL,"pax",NULL,NULL,NULL,NULL,NULL,NULL,NULL,15231968,787,1478,NULL,NULL,1478,787,NULL,NULL,1, NULL,"","travelport","LCC","ECO","0",NULL,NULL,NULL,NULL,"round",1,NULL,1,NULL,0,0,NULL,0,NUL
|
In the example above, a new error entry starts inside the SQL text of the previous entry.
Why this is a bug
The SQL error log should produce atomic, well-delimited entries. Even if a statement is truncated for size reasons, the log entry should remain internally consistent and should never
contain the prefix of another error entry inside the logged SQL text.
Current behavior causes:
- corrupted log records
- misleading syntax diagnostics
- inability to reconstruct the original failing SQL
- failures in tooling that parses sql_errors.log
Impact
- production troubleshooting becomes difficult
- automated error analysis becomes unreliable
- false diagnosis is possible because the logged SQL is already corrupted
- logs cannot be used safely as evidence of the original failing statement
The most problematic cases involved large TEXT / JSON payloads.
Steps to Reproduce
1. Configure MariaDB so that SQL errors are written to sql_errors.log
2. Run a large restore/import using myloader
3. Use data containing long INSERT INTO ... VALUES (...) statements, especially with large JSON/TEXT payloads
4. Trigger multiple SQL errors close together in time
5. Inspect sql_errors.log*
Expected Result
Each SQL error should be written as a separate, well-formed log entry.
A log entry must not contain the prefix of another entry inside its SQL text.
Actual Result
Multiple SQL error entries can be concatenated or interleaved.
A new error entry may begin in the middle of the previous entry’s SQL text, corrupting both entries.
Additional Notes
This looks like a logging integrity issue, possibly related to concurrency, buffering, or non-atomic writes for large log entries.
We had to implement a workaround that reparses the file and inserts a newline before each pattern like:
YYYY-MM-DD HH:MM:SS xxxx[yyyy] @
This only makes the log more readable again; it does not restore the original SQL integrity.