You need an UPDATE trigger for this, since the comparison requires knowledge of
the old and new values.
-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im
Auftrag von Cecil Westerhof
Gesendet: Freitag, 27. Dezember 2019 13:05
An: SQLite
Op vr 27 dec. 2019 om 13:12 schreef Hick Gunter :
> You need an UPDATE trigger for this, since the comparison requires
> knowledge of the old and new values.
>
Of-course. I should have thought of that. :'-(
I will look into that this weekend.
In my case it is not important (I do not expect to
On 27 Dec 2019, at 3:06pm, Cecil Westerhof wrote:
> My applications only use one thread (for the db stuff). Would it be a good
> idea to switch to single-thread mode, or does that not give a real
> performance improvement?
On a desktop computer, or a mobile phone, the increase in speed is not
Hi,
We found an assertion violation bug in sqlite. Here’s the PoC:
—
CREATE TABLE v0 ( v1 INTEGER PRIMARY KEY ) ; INSERT INTO v0 VALUES ( 10 ) ;
SELECT '29' , count () OVER( ORDER BY v1 ) AS m FROM v0 ORDER BY v1 > ( SELECT
m ) ;
—
The bug exists in the latest development code and release
On Donnerstag, 26. Dezember 2019 02:01:36 CET Richard Hipp wrote:
> Tnx for the report. Should be fixed as of
> https://sqlite.org/src/info/c8c6dd0e6582ec91
>
> Please do us the favor of trying this out on both Btrfs and XFS and
> making sure it works correctly on both filesystems. Tnx.
Thanks
Op vr 27 dec. 2019 om 17:01 schreef Simon Slavin :
> On 27 Dec 2019, at 3:06pm, Cecil Westerhof wrote:
>
> > My applications only use one thread (for the db stuff). Would it be a
> good idea to switch to single-thread mode, or does that not give a real
> performance improvement?
>
> On a desktop
My applications only use one thread (for the db stuff). Would it be a good
idea to switch to single-thread mode, or does that not give a real
performance improvement?
If the performance is not really improved, I can better keep the default.
Then there is no risk that I forget the change the mode
Hi Yongheng and Rui,
This might be a duplicate to a bug that I reported, since both test cases
trigger the same assertion error. See
https://sqlite.org/src/tktview?name=37823501c6.
Best,
Manuel
On Fri, Dec 27, 2019 at 6:09 PM Yongheng Chen wrote:
> Hi,
>
> We found an assertion violation bug
On Friday, 27 December, 2019 10:29, Cecil Westerhof
wrote:
>Op vr 27 dec. 2019 om 17:01 schreef Simon Slavin :
>> On 27 Dec 2019, at 3:06pm, Cecil Westerhof wrote:
>>> My applications only use one thread (for the db stuff). Would it be a
>>> good idea to switch to single-thread mode, or
On Friday, 27 December, 2019 12:50, Igor Korot wrote:
>On Fri, Dec 27, 2019 at 12:57 PM Bigthing Do wrote:
>> We met an accidental crash in sqlite with the following sample:
>> CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 )
>> SELECT col2 FROM table1 ORDER BY 1 ;
Hi,
There’s one bug that triggers assertion failed in sqlite:
—
CREATE TABLE v0 ( v1 ) ;
CREATE TABLE v2 ( v3 VARCHAR(1) UNIQUE ) ;
SELECT * FROM v0 WHERE v1 IN ( 'AIR' ) GROUP BY v1 , v1 ;
CREATE INDEX v4 ON v0 ( v1 , v1 , v1 , v1 , v1 , v1 , v1 , v1 , v1 , v1 , v1 ,
v1 , v1 , v1 , v1 )
Hi,
We found some assertion bugs in sqlite:
#1
—
CREATE TABLE v0 ( v1 INTEGER PRIMARY KEY UNIQUE ) ;
INSERT INTO v0 VALUES ( 10 ) ON CONFLICT DO NOTHING ;
SELECT * FROM v0 NATURAL JOIN v0 AS y WHERE v1 IN ( SELECT DISTINCT v1 FROM v0
ORDER BY v1 );
sqlite3.c:100324: Select
Hi,
We tried debugging a little bit with the core dump, it crashes with a null
reference actually:
`
Program received signal SIGSEGV, Segmentation fault.
[--registers---]
RAX: 0x74 ('t')
RBX: 0x782550 --> 0x76b088 --> 0x1
RCX:
> On Dec 26, 2019, at 3:45 PM, Doug wrote:
>
> Can you explain what the API is that you use to "set concurrency levels per
> connection", please? Is it a parameter on open() or its own function call?
> And how would the API break, exactly?
sqlite3_config(), specifically the
On 12/27/19, Richard Hipp wrote:
>
> This is the third such false-positive bug like that this month
And now there is a fourth: https://sqlite.org/src/info/5fbc159eeb092130c6f2
CREATE TABLE t0(c0 NOT NULL DEFAULT 1, c1 AS(c0) UNIQUE);
REPLACE INTO t0 VALUES(NULL);
If you understood my prior
Dear sqlite developers:
We met an accidental crash in sqlite with the following sample:
CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 )
SELECT col2 FROM table1 ORDER BY 1 ;
WITH aaa AS ( SELECT * FROM table1 ) SELECT col1 , rank () OVER( ORDER BY col1
DESC ) FROM
Hi,
We found a heap UAF bug in sqlite. Here’s the PoC:
—
CREATE TABLE v0 ( v1 CHECK( CASE v1 WHEN '13' THEN 10 ELSE 10 END ) ) ; CREATE
TRIGGER x INSERT ON v0 BEGIN INSERT INTO v0 ( v1 , v1 ) SELECT v1 , v1 FROM v0
WHERE v1 < 10 ON CONFLICT DO NOTHING ; END ; INSERT INTO v0 SELECT * FROM v0
Hi Manuel,
Hh, what a coincident. It might be so. The test case looks very different
though. Let’s wait for Richard to find it out then.
Yongheng & Rui
> On Dec 27, 2019, at 2:03 PM, Manuel Rigger wrote:
>
> Hi Yongheng and Rui,
>
> This might be a duplicate to a bug that I reported, since
Hi,
On Fri, Dec 27, 2019 at 12:57 PM Bigthing Do wrote:
>
> Dear sqlite developers:
>
> We met an accidental crash in sqlite with the following sample:
>
> CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 )
> SELECT col2 FROM table1 ORDER BY 1 ;
> WITH aaa AS ( SELECT *
On 28/12/62 01:58, Yongheng Chen wrote:
Hi,
We found a heap UAF bug in sqlite. Here’s the PoC:
—
CREATE TABLE v0 ( v1 CHECK( CASE v1 WHEN '13' THEN 10 ELSE 10 END ) ) ; CREATE
TRIGGER x INSERT ON v0 BEGIN INSERT INTO v0 ( v1 , v1 ) SELECT v1 , v1 FROM v0
WHERE v1 < 10 ON CONFLICT DO NOTHING
On 27 Dec 2019, at 7:46pm, Keith Medcalf wrote:
> Setting "SINGLE THREADED" mode *increased* the elapsed time to 4 minutes.
> (Perhaps it disables some of the internal multithreaded sorters -- I don't
> know).
Can anyone explain this ?
(To save you reading all the stuff I snipped, it's one
On 12/27/19, Manuel Rigger wrote:
> Hi Yongheng and Rui,
>
> This might be a duplicate to a bug that I reported, since both test cases
> trigger the same assertion error. See
> https://sqlite.org/src/tktview?name=37823501c6.
That particular assert() is sort of like an ASAN fault except that it
On Friday, 27 December, 2019 14:19, Simon Slavin wrote:
>On 27 Dec 2019, at 7:46pm, Keith Medcalf wrote:
>> Setting "SINGLE THREADED" mode *increased* the elapsed time to 4
>minutes. (Perhaps it disables some of the internal multithreaded sorters
>-- I don't know).
>Can anyone explain this
Another point being, fully normalized data can be a bear to extract.
I see penalities in my humble database reports, so I leave 3rd and 4th
normalization for managers wish lists. ;)
On Fri, Dec 27, 2019, 6:37 PM Simon Slavin wrote:
> On 27 Dec 2019, at 9:57pm, Keith Medcalf wrote:
>
> >
On 12/27/19, Richard Hipp wrote:
> On 12/27/19, Richard Hipp wrote:
>>
>> This is the third such false-positive bug like that this month
>
> And now there is a fourth: https://sqlite.org/src/info/5fbc159eeb092130c6f2
For those of you still keeping score... A fifth example of this is
ticket
On 27 Dec 2019, at 9:57pm, Keith Medcalf wrote:
> Setting "SINGLETHREAD" does indeed disable the multithreaded sorters. When
> in one of the multithreaded modes, that query utilizes an average of 60% CPU,
> compared to 12% when running singlethreaded.
So if I understand this right, SQLite
On Friday, 27 December, 2019 16:37, Simon Slavin wrote:
>On 27 Dec 2019, at 9:57pm, Keith Medcalf wrote:
>> Setting "SINGLETHREAD" does indeed disable the multithreaded sorters.
>> When in one of the multithreaded modes, that query utilizes an average of
>> 60% CPU, compared to 12% when
Just to have a way to see my progress at Udemy, I created the following
table and view:
CREATE TABLE rawSummaryUdemy (
dateTEXTNOT NULL DEFAULT CURRENT_DATE,
total INTEGER NOT NULL,
completed INTEGER NOT NULL,
CONSTRAINT formatDate
28 matches
Mail list logo
