https://bugs.kde.org/show_bug.cgi?id=417070
--- Comment #12 from Hakan Bayindir <[email protected]> --- Hello Alex, Thanks for the patches and all the hard work. I have a question. As far as understood, the locking in SQLite is as follows [0]: 1. In most cases many clients can have locks on a SQLite DB. 2. If a client is preparing to write, all other locks become read-only. 3. To be able to actually write, all other locks shall clear (i.e. other clients shall close connection). Otherwise writes hang until all other locks clear. Because of 3., Firefox and Chrome claims exclusive locks on all SQLite DBs on startup. Considering the DBs may get extremely big (see my survey about writes in this), can a more sophisticated logic can be implemented? It shall work as follows: 1. If the DBs are not locked, sync the changes to local Bookmark DBs. 2. If the DBs are locked and KDE integration plugins are available, sync the changes over the plugin connection (since plugins can read the bookmarks). This will further reduce the write load on system SSDs since the delta will be much smaller than copying a whole DB over and over. Since SSDs getting cheaper and TBW values doesn't increase significantly over the years, minimizing writes looks like a wise ideal to pursue. What's your opinion on this? Regards, Hakan [0]: https://www.sqlite.org/lockingv3.html On 27 Mayıs 2020 Çarşamba 15:09:15 +03 you wrote: > https://bugs.kde.org/show_bug.cgi?id=417070 > > Alex <[email protected]> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |[email protected] Resolution|--- > |FIXED > Status|CONFIRMED |RESOLVED > > --- Comment #10 from Alex <[email protected]> --- > I already write a patch for this (without knowing of this bug): > > https://phabricator.kde.org/D29726. > > The there were two problems: > 1: The files are deleted/copied for every match session, even if they didn't > changed. They have to be copied because they are locked if the browser is > open. 2: There was a bug that the prepare/teardown signal get called for > each letter typed, this means that the files were copied for each letter > typed (BUG 420311). This has also been fixed. -- You are receiving this mail because: You are watching all bug changes.
