[EMAIL PROTECTED] wrote:
In a message dated 9/2/2004 1:02:17 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
Version 3.0.6 is on the website now.
Dr. Hipp,
Thanks for moving so fast, I will pull and test.
A question, is there an easy way to corrupt a database for testing purposes?
s
In a message dated 9/2/2004 1:02:17 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
Version 3.0.6 is on the website now.
Dr. Hipp,
Thanks for moving so fast, I will pull and test.
A question, is there an easy way to corrupt a database for testing purposes?
such as change some byte
Darren Duncan wrote:
At 6:06 PM -0400 9/1/04, D. Richard Hipp wrote:
A subtle bug has been uncovered
I am assuming, then, that the next release of SQLite will also
officially be beta status,
Correct. Version 3.0.6 is on the website now. Hopefully I will
be able to release 3.0.7 (stable) in
At 6:06 PM -0400 9/1/04, D. Richard Hipp wrote:
I fear that your patch has been overcome by events.
A subtle bug has been uncovered in another area
of locking which is going to require reworking large
sections of the commit/rollback logic. It is very
doubtful that your patch will survive this rewo
On Wed, 1 Sep 2004, D. Richard Hipp wrote:
>Christian Smith wrote:
>> Created ticket #884, with patch against latest cvs:
>> http://www.sqlite.org/cvstrac/tktview?tn=884
>>
>
>I fear that your patch has been overcome by events.
>A subtle bug has been uncovered in another area
>of locking which is
Christian Smith wrote:
Created ticket #884, with patch against latest cvs:
http://www.sqlite.org/cvstrac/tktview?tn=884
I fear that your patch has been overcome by events.
A subtle bug has been uncovered in another area
of locking which is going to require reworking large
sections of the commit/rol
rovided about the status of what it is performing (commit,
>>update, etc).
>>
>>- Original Message -
>>From: "Rob Groves" <[EMAIL PROTECTED]>
>>To: <[EMAIL PROTECTED]>
>>Sent: Wednesday, September 01, 2004 12:34 AM
>>Subject: RE: [sql
"Wei Chin" <[EMAIL PROTECTED]> writes:
> As I try this with SQLITE 3.0.4, I get "database is locked" error at
> step 4.
>
> Are you not getting the lock out error?
Yes, because there is a transaction in progress in Process 2, the database may
not be written to by Process 1, so without a busy-wai
Darrell and everyone,
As I try this with SQLITE 3.0.4, I get "database is locked" error at
step 4.
Are you not getting the lock out error?
Wei
[EMAIL PROTECTED] wrote on 9/1/2004, 10:04 AM:
> TimeProcess 1 Process 2
>
On Wed, 1 Sep 2004, Christian Smith wrote:
A transaction gives you a snapshot in time of the database. You may need to
do more than one query, and require a consistent snapshot for the duration
of the multiple queries.
this is definitely a real world need - in my latest code i have a 'snapshot'
met
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] Locking in 3.0.5
On Wed, 1 Sep 2004, Matt Wilson wrote:
>On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote:
>>
>> Add a new "BEGIN [TRANSACTION] FOR READONLY" statement, which begins
>> the tran
Matt Wilson <[EMAIL PROTECTED]> writes:
> On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote:
>>
>> Add a new "BEGIN [TRANSACTION] FOR READONLY" statement, which begins the
>> transaction with a read lock only and doesn't allow the transaction to
>> even try to promote to a write loc
On Wed, 1 Sep 2004, Matt Wilson wrote:
>On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote:
>>
>> Add a new "BEGIN [TRANSACTION] FOR READONLY" statement, which begins the
>> transaction with a read lock only and doesn't allow the transaction to
>> even try to promote to a write lock.
On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote:
>
> Add a new "BEGIN [TRANSACTION] FOR READONLY" statement, which begins the
> transaction with a read lock only and doesn't allow the transaction to
> even try to promote to a write lock.
Why do you need a transaction at all if you
decide which thread is better to rollback
>since no info is provided about the status of what it is performing (commit,
>update, etc).
>
>- Original Message -
>From: "Rob Groves" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Wednesday, Septe
us of what it is performing (commit,
update, etc).
- Original Message -
From: "Rob Groves" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 01, 2004 12:34 AM
Subject: RE: [sqlite] Locking in 3.0.5
> >>So, Rob, are you go to tell
>>So, Rob, are you go to tell us if you think the change
>>is an improvement or not?
It seems that with either of the new schemes, when using
sqlite3_busy_timeout() one thread is going to timeout sooner
or later. That being the case I prefer the new version on
efficiency grounds.
Being a lazy pro
Rob Groves wrote:
I have just read the archive mailing list from 16/08/2004,
and it looks like this behaviour is on purpose (checkin 1879).
So, Rob, are you go to tell us if you think the change
is an improvement or not?
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
I have just read the archive mailing list from 16/08/2004,
and it looks like this behaviour is on purpose (checkin 1879).
My mistake,
Rob.
-Original Message-
From: Rob Groves [mailto:[EMAIL PROTECTED]
Sent: 31 August 2004 22:17
To: [EMAIL PROTECTED]
Subject: [sqlite] Locking in 3.0.5
Hi,
I have observed different behaviour between 3.0.3 and 3.0.5. I didn't
download 3.0.4 so can't comment on that.
I am using two threads and setting a busy timeout on each with
sqlite3_busy_timeout().
In 3.0.3 two threads trying to update the same row(s) would both retry until
the one with the
20 matches
Mail list logo
