> Le 9 août 2019 à 17:58, Richard Hipp a écrit :
>
> On 8/9/19, David Raymond wrote:
>>
>> I'm pretty sure you missed the bit where he said that there was only a read,
>> and no changes were made or requested.
>>
>
> You are correct - I missed that part. In that case, it just drops the
> SHA
On 8/9/19, David Raymond wrote:
>
> I'm pretty sure you missed the bit where he said that there was only a read,
> and no changes were made or requested.
>
You are correct - I missed that part. In that case, it just drops the
SHARED lock.
--
D. Richard Hipp
d...@sqlite.org
_
>> A connection holds a SHARED lock. It did start a DEFERRED transaction then
>> read something. Now it executes COMMIT.
>You are one of the rollback journaling modes, not WAL mode, right?
>Different rules apply for WAL mode.
>
>In rollback mode, the connection automatically promotes to EXCLUSIVE
On 8/9/19, Olivier Mascia wrote:
> Hello,
>
> I generally understand the locking states of SQLite well enough, I think.
> Though this specific case below caught me off guard. I couldn't give an
> immediate intelligible answer to my coworker. Nor could I find the answer
> on the website, or I'm b
On 8/9/2019 11:00 AM, Olivier Mascia wrote:
A connection holds a SHARED lock. It did start a DEFERRED transaction then read
something. Now it executes COMMIT. Will the lock be upgraded from SHARED to
EXCLUSIVE for the very short duration of the COMMIT (the connection made no
writing, as evide
Hello,
I generally understand the locking states of SQLite well enough, I think.
Though this specific case below caught me off guard. I couldn't give an
immediate intelligible answer to my coworker. Nor could I find the answer on
the website, or I'm blind today.
A connection holds a SHARED
6 matches
Mail list logo
