> Le 2 f?vr. 2016 ? 03:25, Rowan Worth <rowanw at dugeo.com> a ?crit : > > To reiterate, I don't have a problem with sqlite's behaviour at all. I > think it's perfectly acceptable. But I think it deserves to be acknowledged > and understood for what it is; a pragmatic decision by sqlite to improve > performance in the general case at the "expense" of a > not-strictly-necessary rollback in an obscure failure scenario. It's not > fair to meet it with the double standard of "fsyncing the directory every > COMMIT would hurt general-case performance too much" and "the OS is > responsible for ensuring data gets to disk", because that essentially asks > the OS to fsync directory after every *i/o operation*, whether asked to or > not. Which would hurt general-case performance much more! > > I'm right there behind you that it shouldn't be forced on users of sqlite :)
Indeed, and those users insisting on using journal_mode=DELETE while living with a filesystem requiring an fsync of the directory after create/remove files, could also fsync() the directory themselves after the SQLite successful commit, before considering it "done". Or they could use one of the alternates modes which do not delete the journal, but either reset it (TRUNCATE) or clear it (PERSIST). Or even consider WAL mode which has very interesting properties, in itself. https://www.sqlite.org/pragma.html#pragma_journal_mode Compared to the amount of (generally bad) sample code seen on the internet (outside of sqlite.org) where people seem to think it is ordinary business to do PRAGMA synchronous=OFF or even PRAGMA journal_mode=OFF, I live happily with this journal_mode=DELETE (which I happen to not use). :) -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/attachments/20160202/2d3d45f0/attachment.pgp>
