Bug#255276: Patch to run database recovery on startup
The patch is risky. After it's been applied, invoking /etc/init.d/slapd start while slapd is running can (and most probably will) result in data loss. db4.2_recover -e will pick up new DB_CONFIG settings, so there's no need to special-case it for updates. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255276: Patch to run database recovery on startup
Hi Florian, On Fri, May 27, 2005 at 08:27:47AM +0200, Florian Weimer wrote: The patch is risky. After it's been applied, invoking /etc/init.d/slapd start while slapd is running can (and most probably will) result in data loss. Yep, that is creating headaches for me too :( db4.2_recover -e will pick up new DB_CONFIG settings, so there's no need to special-case it for updates. Are you sure? I though -e was to retain the old setting? Greetings Torsten signature.asc Description: Digital signature
Bug#255276: Patch to run database recovery on startup
* Torsten Landschoff: db4.2_recover -e will pick up new DB_CONFIG settings, so there's no need to special-case it for updates. Are you sure? Yes, I regularly use -e to recreate the environment after tweaking DB_CONFIG. I though -e was to retain the old setting? -e does not retain any settings, it retains the environment. The settings are taken from DB_CONFIG and the compiled-in default values, not from the previous environment configuration. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255276: Patch to run database recovery on startup
* Florian Weimer: I though -e was to retain the old setting? -e does not retain any settings, it retains the environment. It retains it by removing and recreating it (sorry for being unclear). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
