Dan Kennedy writes:
> On Aug 25, 2010, at 10:40 PM, Pavel Ivanov wrote:
>
>> Nikolaus,
>>
>> I've traced your application a bit (with SQLite 3.6.18 sources) and
>> it looks like SQLite does some nasty thing nobody in this thread
>> expected. For some reason while doing first delete SQLite actuall
On Aug 25, 2010, at 11:04 PM, Pavel Ivanov wrote:
>> Prior to version 3.6.5 SQLite used to delay committing the
>> transaction until all SELECT statements had finished. But that
>> behavior was deemed to be less intuitive.
>
> But this is the current 3.7.1 documentation
> (http://www.sqlite.org/l
> Prior to version 3.6.5 SQLite used to delay committing the
> transaction until all SELECT statements had finished. But that
> behavior was deemed to be less intuitive.
But this is the current 3.7.1 documentation
(http://www.sqlite.org/lockingv3.html):
If multiple commands are b
On Aug 25, 2010, at 10:40 PM, Pavel Ivanov wrote:
> Nikolaus,
>
> I've traced your application a bit (with SQLite 3.6.18 sources) and
> it looks like SQLite does some nasty thing nobody in this thread
> expected. For some reason while doing first delete SQLite actually
> commits transaction and
Nikolaus,
I've traced your application a bit (with SQLite 3.6.18 sources) and
it looks like SQLite does some nasty thing nobody in this thread
expected. For some reason while doing first delete SQLite actually
commits transaction and degrades lock to SHARED. Then of course second
delete cannot be
Doug Currie writes:
> On Aug 24, 2010, at 10:57 AM, Nikolaus Rath wrote:
>
>> Nikolaus Rath
>>
>> writes:
>>> Still no one able to clarify the issues raised in this thread?
>>>
>>> Let me try to summarize what I still don't understand:
>>>
>>> - Will SQLite acquire and release an EXCLUSIVE lock
Hi,
I only saw http://article.gmane.org/gmane.comp.db.sqlite.general/58835,
was there anything else?
-Nikolaus
Gerry Snyder writes:
> Er, did you not see Dan Kennedy's comments a fed days ago??
>
> On 8/24/10, Nikolaus Rath wrote:
>> Nikolaus Rath
>> writes:
>>> Still no one able to clarify
On Aug 24, 2010, at 10:57 AM, Nikolaus Rath wrote:
> Nikolaus Rath writes:
>> Still no one able to clarify the issues raised in this thread?
>>
>> Let me try to summarize what I still don't understand:
>>
>> - Will SQLite acquire and release an EXCLUSIVE lock while keeping a
>> SHARED lock i
Er, did you not see Dan Kennedy's comments a fed days ago??
On 8/24/10, Nikolaus Rath wrote:
> Nikolaus Rath writes:
>> Still no one able to clarify the issues raised in this thread?
>>
>> Let me try to summarize what I still don't understand:
>>
>> - Will SQLite acquire and release an EXCLUSIV
Nikolaus Rath writes:
> Still no one able to clarify the issues raised in this thread?
>
> Let me try to summarize what I still don't understand:
>
> - Will SQLite acquire and release an EXCLUSIVE lock while keeping a
>SHARED lock if one executes a UPDATE query with one cursor while a
>di
On Thu, Aug 19, 2010 at 07:54:19PM +0100, Simon Slavin scratched on the wall:
> I don't know what you mean by 'cursor'. SQLite has commands. You
> execute one command at a time. Even a command like a SELECT that
> gathers lots of data gathers the data all in one go, then finishes.
None of
On 19 Aug 2010, at 8:06pm, Pavel Ivanov wrote:
> Simon, read the whole thread please. Here is an example of 'cursor' in
> SQLite which Nikolaus talks about:
Thanks. I didn't know about the SQLite internals involved. Thanks for posting
the detailed information.
Simon.
> I don't know what you mean by 'cursor'. SQLite has commands. You execute
> one command at a time. Even a command like a SELECT that gathers lots of
> data gathers the data all in one go, then finishes. SQLite does not mark its
> place with one command, then return to that place again with
On 18 Aug 2010, at 6:33pm, Nikolaus Rath wrote:
> Still no one able to clarify the issues raised in this thread?
>
> Let me try to summarize what I still don't understand:
>
> - Will SQLite acquire and release an EXCLUSIVE lock while keeping a
> SHARED lock if one executes a UPDATE query with
Nikolaus Rath writes:
> Dan Kennedy writes:
>> On Aug 17, 2010, at 1:48 AM, Nikolaus Rath wrote:
>>
>>> Hello,
>>>
>>> The script below fails with
>>>
>>> Deadlock detected when executing 'DELETE FROM foo WHERE id=2'
>>>
>>> What I think should be happening instead is this:
>>>
>>> - When executi
Dan Kennedy writes:
> On Aug 17, 2010, at 1:48 AM, Nikolaus Rath wrote:
>
>> Hello,
>>
>> The script below fails with
>>
>> Deadlock detected when executing 'DELETE FROM foo WHERE id=2'
>>
>> What I think should be happening instead is this:
>>
>> - When executing statement 1, the main thread obta
On Aug 17, 2010, at 1:48 AM, Nikolaus Rath wrote:
> Hello,
>
> The script below fails with
>
> Deadlock detected when executing 'DELETE FROM foo WHERE id=2'
>
> What I think should be happening instead is this:
>
> - When executing statement 1, the main thread obtains a SHARED lock.
> - When exe
"Igor Tandetnik" writes:
> Nikolaus Rath wrote:
>> What I think should be happening instead is this:
>>
>> - When executing statement 1, the main thread obtains a SHARED lock.
>>
>> - When executing statement 2, the main thread briefly obtains an
>> EXCLUSIVE lock. After statement 2 is execut
Nikolaus Rath wrote:
> What I think should be happening instead is this:
>
> - When executing statement 1, the main thread obtains a SHARED lock.
>
> - When executing statement 2, the main thread briefly obtains an
> EXCLUSIVE lock. After statement 2 is executed, the EXCLUSIVE lock is
> rele
Dan Kennedy writes:
> On Aug 17, 2010, at 1:48 AM, Nikolaus Rath wrote:
>
>> Hello,
>>
>> The script below fails with
>>
>> Deadlock detected when executing 'DELETE FROM foo WHERE id=2'
>>
>> What I think should be happening instead is this:
>>
>> - When executing statement 1, the main thread obta
On Aug 17, 2010, at 1:48 AM, Nikolaus Rath wrote:
> Hello,
>
> The script below fails with
>
> Deadlock detected when executing 'DELETE FROM foo WHERE id=2'
>
> What I think should be happening instead is this:
>
> - When executing statement 1, the main thread obtains a SHARED lock.
>
> - When ex
Hello,
The script below fails with
Deadlock detected when executing 'DELETE FROM foo WHERE id=2'
What I think should be happening instead is this:
- When executing statement 1, the main thread obtains a SHARED lock.
- When executing statement 2, the main thread briefly obtains an
EXCLUSIV
22 matches
Mail list logo