Re: [sqlite] Why the deadlock?

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.

Re: [sqlite] Why the deadlock?

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 >

Re: [sqlite] Why the deadlock?

> 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

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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? >>> >>>

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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.

Re: [sqlite] Why the deadlock?

> 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

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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: >>

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

"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,

Re: [sqlite] Why the deadlock?

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

Re: [sqlite] Why the deadlock?

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: >>

Re: [sqlite] Why the deadlock?

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

[sqlite] Why the deadlock?

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