Commit 69c3cf70 authored by Carlos Garnacho's avatar Carlos Garnacho

libtracker-data: Drop unconditional locks around wal checkpoints

This can happen from 2 different places:
1) Idly on a thread. In this case it uses a dedicated interface, so
   there's no need to lock it. We use a passive checkpoint, so it
   will also bail out if there are other readers or writers.
2) Immediately on pressure. This will happen during database updates
   (eg. while stepping on a prepared statement). This case may happen
   from within other places we lock the interface
   (eg. tracker_db_interface_execute_vquery). This path will actually
   lead to deadlocks, as we try to lock the mutex while already holding
   it. And anyway this will happen on an interface dedicated to updates
   used from a single thread.

Just drop the lock/unlock calls here. We don't need them. Fixes deadlocks
seen on case number 2.
parent ea806694
......@@ -1963,11 +1963,9 @@ tracker_db_interface_sqlite_wal_checkpoint (TrackerDBInterface *interface,
{
int return_val;
tracker_db_interface_lock (interface);
return_val = sqlite3_wal_checkpoint_v2 (interface->db, NULL,
blocking ? SQLITE_CHECKPOINT_FULL : SQLITE_CHECKPOINT_PASSIVE,
NULL, NULL);
tracker_db_interface_unlock (interface);
if (return_val != SQLITE_OK) {
g_set_error (error,
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment