On 7 Jul 2010, at 14:20, Benoit Chesneau wrote: > On Wed, Jul 7, 2010 at 1:40 PM, Jan Lehnardt <j...@apache.org> wrote: >> >> On 7 Jul 2010, at 08:31, Benoit Chesneau wrote: >> >> I dislike to have too much options though. >>> >>> @damien >>> I don't understand this "keep it for 1.0" mantra. Since it's more a >>> "philosophical" change than a technical one, I would prefer that >>> change on 1.0 whatever this number means. How do people use CouchDB >>> in production ? Is delayed_commit turned off most of the time ? >> >> I am with Damien, all other releases ship with the current default setting. >> Changing it *a day* before 1.0 does not sound like the way to go. >> >> > > right, it may be too late to do that now. > > Anyway rereading the doc we provide, I think delayed_commit don't > break the promise since db is always in consistent state.
"consistent state" means CouchDB can start up and use that db without andy fixup phase (c.f myisamchk, or InnoDB log-replay). > But we may need like you said, to clarify some docs imo and maybe give > to users some tricks to help them to flush to disk before any machine > shutdown or such ? > >>> About the use on laptop and co, laptops are likely less stable than >>> server machines, and we tend to shutdown them more often too. With >>> delayed_commit=True, when someone shutdown his laptop and forget to >>> apply delayed commit (and most of the time, if we don't automatize >>> that, I bet he will), data in memory will be lost. >> >> I remember two instances of data loss with CouchDB 0.7 on Mac OS X >> when Erlang wasn't using the fully reliable FULLFSYNC option to flush >> data to disk (which is btw more reliable than on any other system). After >> we patched Erlang to do the right thing on Mac OS X, I haven't heard >> of a single instance of data loss on a laptop or anywhere else. >> >> > > There was a recent discussion about couchdb shutdown that was raised > by this default settings. In my case I never lost data but just > because I set couchdb as the last to shutdown. Are you referring to the init script (ours?) that should send a POST /_ensure_full_commit before killing CouchDB? If it is our script, we need to fix it (not a blocker, I'd say). If it is somebody else's script, we should get in touch and help getting it fixed. >>> As a user of openbsd, one of the reasons I use this system (except >>> its simplicity) is that it is secured by default on the contrary most >>> linuxes/bsds aren't. Most of the openbsd users know that security will >>> impact performances. I think I would prefer to have a completly safe >>> couchdb even if performances decreased. >> >> This brings up an interesting point: we ship the CouchDB source. >> Most users use CouchDB through some distribution (apt-get, rpm, >> CouchDBX etc.). The distributors should decide for their users which >> setting is best. >> > > That's indeed a way to handle that, this is again a doc problem I guess. > >> Again, I'd like to keep the default we had forever and commence >> with the release of 1.0. > > for both reasons here, you have my +1 :) Hooray :) Cheers Jan --
