tag:blogger.com,1999:blog-16959946.post6338218864607431955..comments2023-12-09T16:44:47.897+01:00Comments on The Data Charmer: MySQL 5.6 too verbose when creating data directoryGiuseppe Maxiahttp://www.blogger.com/profile/15801583338057324813noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-16959946.post-58059711471674432722012-08-22T17:02:15.458+02:002012-08-22T17:02:15.458+02:00Oracle is making, mysql similar to oracle (complex...Oracle is making, mysql similar to oracle (complex). So, that every body is forced to take mysql support from oracle. Without which resolution won't be possible.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-16959946.post-43132974930463324572012-04-04T19:44:25.256+02:002012-04-04T19:44:25.256+02:00@anonymous,
the purpose of mysqld --bootstrap is t...@anonymous,<br />the purpose of mysqld --bootstrap is to create a data directory. What the user wants at this stage is "it was installed" or "it was not installed, and this is the reason".<br /><br />Anything else, is just too much information, which forces the user to look for signs of errors in this avalanche of text.<br /><br />By polluting the screen this way, you aren't doing the user a favor.Giuseppe Maxiahttps://www.blogger.com/profile/15801583338057324813noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-81538861529834615802012-04-04T19:34:10.086+02:002012-04-04T19:34:10.086+02:00Maybe there is room for compromise.
During install...Maybe there is room for compromise.<br />During install/bootstrap, maybe some of this information is extraneous. An obvious step here would be to cut back on the detailed shutdown information.<br />(In normal operation this would be useful to users with large installations where shutting down can take a very long time.)<br />For now, grep is the easy and obvious fix for normal operation, but recent servers have analogs of sql_print_error/info/warning() for use by plugins, so who knows what the future might hold once everything goes through a central facility?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-16959946.post-71340275093974937632012-03-19T08:48:30.075+01:002012-03-19T08:48:30.075+01:00@anonymous,
Let's try not to convert this disc...@anonymous,<br />Let's try not to convert this discussion into a bicycle shed color debate.<br />The issue here is that developers do this kind of thing because they need debugging information (it happened with the event scheduler, which was writing every event start and stop to the error log and was removed after popular outcry) and some of the developers don't try to put themselves in the DBA's shoes.<br />So, ask any DBA if they consider useful to mix notices and errors, and see what you get.<br />And ask anyone who needs to write a wrapper around the bootstrap to package MySQL for a specific installer, if they find this new "feature" useful, and see what kind of consensus you may get.Giuseppe Maxiahttps://www.blogger.com/profile/15801583338057324813noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-88262882839978589702012-03-19T03:18:16.988+01:002012-03-19T03:18:16.988+01:00> What is not acceptable is using standard erro...> What is not acceptable is using standard error for things that should go to the standard output. <br /><br />A notice is appropriate for stderr.<br /><br />> Moreover, a procedure that for more than a decade has written to standard error only when an error occurs, should not change its behavior.<br /><br />There might be no change in behavior, historically all messages are written to stderr if not redirected (and this is actually the problem... see print_buffer_to_file).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-16959946.post-92102631731531610572012-03-18T22:36:49.911+01:002012-03-18T22:36:49.911+01:00I can spot another bug: the reference to mysqlbug....I can spot another bug: the reference to mysqlbug. <a href="http://bugs.mysql.com/bug.php?id=43870" rel="nofollow">#43870</a> <a href="http://bugs.mysql.com/bug.php?id=29716" rel="nofollow">#29716</a>Daniël van Eedenhttps://www.blogger.com/profile/14757324605223498151noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-62110185685139727362012-03-18T16:30:38.176+01:002012-03-18T16:30:38.176+01:00@anonymous,
> also for diagnostic output.
True...@anonymous,<br />> <i>also for diagnostic output.</i><br /><br />True, and also in this case it is expected to get text separated from the regular output.<br /><br />What is not acceptable is using standard error for things that should go to the standard output. <br /><br />Moreover, a procedure that for more than a decade has written to standard error only when an error occurs, should not change its behavior.Giuseppe Maxiahttps://www.blogger.com/profile/15801583338057324813noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-77096246748157489982012-03-18T16:23:39.352+01:002012-03-18T16:23:39.352+01:00> [..] output that should be reserved for, well...> [..] output that should be reserved for, well, errors! <br /><br />Actually, it's also for diagnostic output.Anonymousnoreply@blogger.com