This was one of the best posts I have read. No ego chest thumping - just knowledgable experience-based support.
Shout out to the original poster for providing such thorough detail on the problem. This allowed the experts to quickly identify the possible problem and potential solution quickly. This thread was helpful for less experienced people like me quickly follow the performance problem and solution. Appreciated, Steve Sent from my iPhone > On Jul 3, 2015, at 8:47 AM, Simon Slavin <slavins at bigfraud.org> wrote: > > >> On 3 Jul 2015, at 2:31pm, Mikael <mikael.trash at gmail.com> wrote: >> >> Wait, so if connection 1 is doing VACUUM and connection 2 attempts >> INSERT/UPDATE/DELETE and connection 3 attempts SELECT all concurrently, >> what happens and how ACID will the DB be? > > VACUUM locks the database, just like INSERT and UPDATE. Other writing > operations will be forced to wait until the VACUUM is complete and the > database is unlocked again. > > Depending on your settings and journal mode, read operations will (I believe) > read the uncommitted changes from the 'old' copy of the table, or will be > delayed until the VACUUM is complete. Whichever it is, they should get > correct data. > > Of course, waiting for VACUUM may take far longer than waiting for a single > INSERT or UPDATE, which is why you need a longer timeout setting than just a > few seconds. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
