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 runnin
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:
>
> > Setting
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 in
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 ?
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
> 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 SQLITE_CONFIG_SIN
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 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 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
is
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: 0x61
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 ) WHERE
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 *isCandidateForInOpt
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,
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 * F
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 does
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 b
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 i
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
W
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 tab
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
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 code.
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
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 wh
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 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 in
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 m
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 CHEC
28 matches
Mail list logo