Re: SQLite locking and FSFS rep-sharing

Philip Martin <philip.martin_at_wandisco.com> writes:

> The second commit doesn't wait for the 10 second SQLite busy timeout, it
> gives the 'database is locked' error immediately.

r1137660 changed the rep-cache update to optimise for the common case
when the reps are not already present. It means that most of the time
the update will only use INSERT statements and no SELECT statements. It
has is an unintended side-effect: it appears to make the SQLITE_BUSY
timeout apply before I see the 'database is locked' error, and if I
release the lock during that timeout the error doesn't get raised.

-- 
Philip