Posted by John Scoles on Apr 30, 2009
The “Sesame Street” Version of DBD::Oracle (1.23) has been released.
You can find it at CPAN DBD::Oracle.
DBD::Oracle is the Perl module that works with the DBI module to provide access to Oracle databases. It is maintained by me, John Scoles, under the auspices of The Pythian Group as open source/free software.
This release is largely a maintenance release that fixes a number of bugs.
New stuff includes the ability to fetch Oracle embedded types directly into an oracle object; a big thank you goes out to Tomas Pokorny for that patch.
Also, UTF8 support has been expanded and cleaned up for BLOBs and execute_array and thanks go out to Milo van der Leij, David Mansfield for most of the work on this.
Also a big thanks Alex Buttery, Jim McCullars, Charles Jardine, Eric Simon, and Chris Underhill, who helped out with some clean up of the code, READMEs, and the POD.
I have also now added two private statement functions ora_stmt_type_name and ora_stmt_type which will get the OCI type name and type for the currently prepared statement.
The complete change list
Read the rest of this entry . . .
Posted by Sheeri Cabral on Jun 6, 2008
According to the manual, FLUSH LOGS is supposed to:
Closes and reopens all log files. If binary logging is enabled, the sequence number of the binary log file is incremented by one relative to the previous file. On Unix, this is the same thing as sending a SIGHUP signal to the mysqld server (except on some Mac OS X 10.3 versions where mysqld ignores SIGHUP and SIGQUIT).
If the server is writing error output to a named file (for example, if it was started with the –log-error option), FLUSH LOGS causes it to rename the current error log file with a suffix of -old and create a new empty log file. No renaming occurs if the server is not writing to a named file (for example, if it is writing errors to the console).
There is a bug, however. In the case when the error log writes to a non-default path, FLUSH LOGS actually does not work as specified for the error log. I have not seen issues with binary logs in non-default paths, but we just ran into this issue on a client site and it threw us for a big loop, and we had to wait for an appropriate downtime window so we could actually restart the server so the logfile was rotated and written to appropriately.
The bug description is here: http://bugs.mysql.com/bug.php?id=19642
and is actually a duplicate of: http://bugs.mysql.com/bug.php?id=6061
This is a pretty serious bug in my opinion, and it’s only fixed in MySQL 5.1 — there are no patches or fixes for 4.1 or 5.0.
