"But if it was a Rails bug, I would think this would be biting a lot
of people, not just me."
Thanks for your post. It took me all day just to find this page. It
took the morning just to figure out that this was the problem. Since I
upgraded to Rail 2.0.2, all "rake db:migrate RAILS_ENV=production"
commands will fail if the migration contains any ActiveRecord commands
(that would normally be logged in development mode) -- i.e. commands
like [Model].find(:all), [object].update_attribute(...), etc. No
problem if the migration file contains only regular migration commands
(e.g. add_column, drop_table, etc.).
I tried your suggestion (RAILS_DEFAULT_LOGGER.auto_flushing = true)
but that only made things worse for me. That is, without that command,
the rake command would eventually break and die (MySql lock would time
out). But with this command, rake just hangs there forever.
Why this bug hasn't been found yet? I suspect it's a pretty narrow
case involving ActiveRecord, rake, and logger. My situation would seem
common enough to have been found by others. But one can alway work
around elegance to keep the trains moving.
As for me, after 7 hours of banging my head on this obscure issue,
I'll just go back to a truly awful workaround (i.e. sftp 'get' the
production db to my local machine, slurp that data into my local
devlopment db, run the migration locally, sftp 'put' the updated db
back up to the server, slurp it in into the production db). Maybe on
another day I'll do more than browse through the rails code in
bewilderment, and actually find, fix, and publish the bug/fix. But
that day is not today.