Description:
I posted the following in dev-* and asked whether it
should be consider a bug. Serg said yes, so here it
is. :-)
I was under the impression that BDB logs are always of the form
"log.nnnnnnnnnn" where the extension is a 10-digit value. I guess
that might be true for the logs that BDB *creates*, but it appears
that its behavior during server startup is a bit different.
Here is my tale:
I usually run my servers with the general query log enabled, and I
do so with a --log=log option. That creates a log file named "log"
in the data directory. And it works just fine. Server starts, runs,
stops, restarts normally.
Now I introduce a cron job that rotates the log file, using the names
log.1, log.2, ... , log.7. That works well, too. My logs rotate
and don't fill up my disk, and I'm happy.
Now I shut down the server. That works.
Now I restart the server with mysqld_safe and quickly see "mysqld ended".
Hm. Looking in the .err file, I see this:
bdb: Invalid log file: log.1: No such file or directory
bdb: PANIC: No such file or directory
bdb: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
bdb: fatal region error detected; run recovery
The filename might vary in the first message, but it will always be one of my
rotated log files.
As it turns out, it is not really necessary to run recovery. All I need
to do is remove my log.[1-7] files and the server will startup normally.
I am wondering whether this should be considered a bug, or whether instead
I should consider myself to have committed an error in using rotated log
files that bear a superficial resemblance to the BDB log file names.
On the one hand, it can be considered poor form to use query log names
of log, log.1, log.2, etc. On the other hand, I was surprised by the
behavior, because the set of filenames that BDB looks for on startup
is much broader than the set of names that it creates.
So my question: Is it reasonable to consider this a bug, or am I a dope
for using such filenames for the general query log? :-)
How to repeat:
See above.
Suggested fix:
I would guess it lies somewhere in bdb/log/log.c,
around line 414 or so...
