[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?
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
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)
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
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
at 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
&
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.
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, September 01, 2004 12:34
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
>>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
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
13 matches
Mail list logo
