RSQLite was released

Author: gaborcsardi

content/post/2021-03-10-rsqlite-parallel/index.Rmd

@@ -20,7 +20,7 @@ Note that this is an oversimplified description of how SQLite works and I will n
 ## TL;DR
 
 -   Always set the SQLite busy timeout.
--   If you use Unix, update RSQLite to the version that will be released soon.
+-   If you use Unix, update RSQLite to at least version 2.2.4.
 -   Use `IMMEDIATE` write transactions. (You can make use of the `dbWithWriteTransaction()` function at the end of this post.)
 
 ## Concurrency in SQLite
@@ -45,11 +45,11 @@ Note that SQLite currently does *not* schedule concurrent transactions fairly. M
 
 ## The `usleep()` issue
 
-Unfortunately previous versions of RSQLite had an issue that prevented good concurrent (write) database performance on Unix. When a connection waits on a lock, it uses the `usleep()` C library function on Unix, but only if SQLite was compiled with the `HAVE_USLEEP` compile-time option. Previous RSQLite versions did not set this option, so SQLite fell back to using the `sleep()` C library function instead. `sleep()` , however can only take an integer number of seconds. Sleeping at least one second between retries is obviously very bad for performance, and it also reduces the number of retries before a certain busy timeout expires, resulting in much more errors. (Or you had to set the timeout to a very large value.)
+Unfortunately RSQLite version before 2.2.4 had an issue that prevented good concurrent (write) database performance on Unix. When a connection waits on a lock, it uses the `usleep()` C library function on Unix, but only if SQLite was compiled with the `HAVE_USLEEP` compile-time option. Previous RSQLite versions did not set this option, so SQLite fell back to using the `sleep()` C library function instead. `sleep()` , however can only take an integer number of seconds. Sleeping at least one second between retries is obviously very bad for performance, and it also reduces the number of retries before a certain busy timeout expires, resulting in much more errors. (Or you had to set the timeout to a very large value.)
 
 Several people experienced this over the years, and we also ran into it in the [liteq package](https://github.com/r-lib/liteq/issues/28). Luckily, this time [Iñaki Ucar](https://github.com/Enchufa2) was persistent enough to track down the issue. The [solution](https://github.com/r-dbi/RSQLite/pull/345) is simple enough: turn on the `HAVE_USLEEP` option. (`usleep()` was not always available in the past, but nowadays it is, so we don't actually have to check for it.)
 
-If you have concurrency issues with RSQLite, please update to the version that will be released, very soon.
+If you have concurrency issues with RSQLite, please update to version 2.2.4 or later.
 
 ## Avoiding deadlocks