MySQL Bugs: #36437: problem with STDERR and STDOUT redirection

Bug #36437	problem with STDERR and STDOUT redirection
Submitted:	30 Apr 2008 17:59
Reporter:	Matthew Lord	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Command-line Clients	Severity:	S3 (Non-critical)
Version:	5.0.56sp1	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	mysqlc, stderr

Description:
When not redirecting STDOUT and STDERR to a file you get the output from running this script in the order you expect (The last create table fails with a syntax
error):

 mysql -u root -vvv < /tmp/compileTESTING.sql
--------------
select count(*) from mysql.user
--------------

+----------+
| count(*) |
+----------+
|        7 | 
+----------+
1 row in set (0.00 sec)

--------------
CREATE TABLE IF NOT EXISTS mytemptable_ankit ( myint int )
--------------

Query OK, 0 rows affected, 1 warning (0.00 sec)

--------------
create table ankit123 (asl mnum)
--------------

ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'mnum)' at line 1

When you redirect it to a file the ERROR(s) are at the very top of the file:

mysql -u root -vvv < /tmp/compileTESTING.sql > /tmp/foo 2>&1
head /tmp/foo 
ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'mnum)' at line 1
--------------
select count(*) from mysql.user
--------------

+----------+
| count(*) |
+----------+
|        7 | 
+----------+
...

How to repeat:
See above.  compileTESTING.sql is attached.

Suggested fix:
I'm not sure that we can do anything about it or not but I'm hoping that it's due
to a bug in how we're doing the redirection.

Test file

Attachment: compileTESTING.sql (application/octet-stream, text), 177 bytes.

repeated with 4.1.23, 5.1.24, 6.0.4 and 5.0.20a.

Hi,

We have a slight but more serious variant of this on 5.0.45 in that stderr will interrupt stdout if both are being directed to a file. Shown below is a segment of such a file (with table name changed):

...
--------------
INSERT INTO <table> VALUES (6329, '3941', 'PH2281')
--------------

Query OK, 1 row affected

--------------
INSERT INTO <table> VALUES (6329, '395', 'AP2789ERROR 1062 (23000) at line 1783: Duplicate entry 'CP860075' for key 1 ERROR 1062 (23000) at line 1787: Duplicate entry 'GS602' for key 1 ERROR 1062 (23000) at line 1788: Duplicate entry 'GS602' for key 1 ERROR 1062 (23000) at line 1796: Duplicate entry 'BE45' for key 1 ERROR 1062 (23000) at line 1798: Duplicate entry 'BE45' for key 1
')
--------------

Query OK, 1 row affected

The first line of the second query begins with stdout, but is then interrupted by stderr. Stdout then resumes on the last line. This throws our error-reporting out big-time as not only is the first line interrupted by this block of stderr, the block of stderr is not in the right sequence either as each error message should follow a statement if the interleaving of stderr with stdout was in chronological order.

Isn't this a bit more serious than just a minor bug if stdout & stderror aren't interleaving properly from the mysql command-line client?

We're on Solaris 10 & the error is reproducible.