On 02/01/2016 11:43 AM, Richard W.M. Jones wrote: > On Mon, Feb 01, 2016 at 11:39:33AM +0100, Florian Weimer wrote: >> On 02/01/2016 11:26 AM, Richard W.M. Jones wrote: >>> On Mon, Feb 01, 2016 at 11:13:08AM +0100, Florian Weimer wrote: >>>> On 02/01/2016 10:59 AM, Richard W.M. Jones wrote: >>>> >>>>> Even if the RPM database is only accessed via librpm, it's still >>>>> important that the most central database present on every Fedora >>>>> system is reliable, well-tested and flexible. Sqlite is a highly >>>>> regarded piece of software, which runs on billions of Android phones. >>>> >>>> That's a strange argument because SQLite is optimized for the mobile use >>>> case, where durability is not a concern: >>>> >>>> <http://article.gmane.org/gmane.comp.db.sqlite.general/99223> >>> >>> I don't see that this posting backs up what you are saying. Of course >>> databases don't perform the impossible - you have to wait for the >>> commit to succeed before the data is persisted, anything else requires >>> backup power supplies and redundant disks. But sqlite is much more >>> likely to be durable than some hand-written brand new code. >> >> Please read the thread. SQLite does not persist the unlink operation on >> the journal, and an existing valid journal file triggers transaction >> rollback. > > Can you point to the messages? I only see two messages in that > thread, and neither uses the word "unlink". Sorry, the rest of the thread is here: <http://thread.gmane.org/gmane.comp.db.sqlite.general/99112> I expect SQLITE_EXTRA_DURABLE=1 will be the default, considering that XFS and Ceph both need it to get durability. In the unlikely scenario that upstream does not change their opinion, we'll should still enable it by default, at least for synchronous=full mode. Curiously, the documentation of pragma SYNCHRONOUS is completely correct—it only talks about preserving database integrity, not about preserving the last committed transaction. > It's good that sqlite is having discussions about durability however. > One thing we can be sure is that only a minute fraction of that > developer effort will be spent examining problems in the new RPM > database code. On the other hand, the RPM locking requirements are somewhat peculiar, and it's not clear whether SQLite is a good match. Florian -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
