Re: [sqlite] SLOW execution: Simple Query Uses More than 1 min

On Monday, 9 December, 2019 20:02, Richard Damon wrote: >On 12/9/19 4:25 PM, Keith Medcalf wrote: >>> You could still have fast forking without overcommitting, you’d just >>> pay the cost in unreachable RAM. >>> If I have 4 GB of RAM in the system, and the kernel takes 1 GB of >>> that, I

Re: [sqlite] SLOW execution: Simple Query Uses More than 1 min

On 12/9/19 4:25 PM, Keith Medcalf wrote: >> You could still have fast forking without overcommitting, you’d just pay >> the cost in unreachable RAM. >> >> If I have 4 GB of RAM in the system, and the kernel takes 1 GB of that, I >> start a 2.5 GB user space process, and my process forks itself

Re: [sqlite] SLOW execution: Simple Query Uses More than 1 min

>You could still have fast forking without overcommitting, you’d just pay >the cost in unreachable RAM. > >If I have 4 GB of RAM in the system, and the kernel takes 1 GB of that, I >start a 2.5 GB user space process, and my process forks itself with the >intent of starting an 0.1 GB process, that

Re: [sqlite] SLOW execution: Simple Query Uses More than 1 min

On Dec 9, 2019, at 12:54 PM, Richard Damon wrote: > > But without virtual memory, many applications combinations that work > acceptably now would just fail to run at all. You don’t even have to get into swapping to find such cases. I once ran a headless app on a small cloud VPS that would run

Re: [sqlite] SLOW execution: Simple Query Uses More than 1 min

But without virtual memory, many applications combinations that work acceptably now would just fail to run at all. Virtual memory itself isn’t the issue. Also, an OS could fairly easily be set up so an application that start to thrash its virtual memory is dropped in priority to get memory, and

Re: [sqlite] A crash bug in sqlite

On 12/9/19, Rui Zhong wrote: > I tried in latest trunk version which check in > commit 926f796e8feec15f3836aa0a060ed906f8ae04d3 and it crashed. > I did not see any more recent commit in GITHUB. Could you please > double check it? GitHub is a mirror. The mirror is updated about once per hour.

Re: [sqlite] A crash bug in sqlite

I tried in latest trunk version which check in commit 926f796e8feec15f3836aa0a060ed906f8ae04d3 and it crashed. I did not see any more recent commit in GITHUB. Could you please double check it? Richard Hipp 于2019年12月9日周一 下午1:23写道： > On 12/9/19, Rui Zhong wrote: > > Hi, > > We found this bug

[sqlite] Slightly offtopic: indexes vs. hash tables

During the lower-volume weekdays, I beg you indulgence for another off-topic post. This article contrasts hash tables vs. indexes, in an attempt to explain why indexes are the basis of most DBMSes but hash tables are the basis of

Re: [sqlite] A crash bug in sqlite

On 12/9/19, Rui Zhong wrote: > Hi, > We found this bug can be triggered again after fix. Yes. I discovered the same thing independently. The previous fix was subtly wrong. Please try the latest trunk version. -- D. Richard Hipp d...@sqlite.org ___

Re: [sqlite] A crash bug in sqlite

Hi, We found this bug can be triggered again after fix. PoC and sqlite version info had been attached as follow. -- SQLite version 3.31.0 2019-12-09 17:14:48 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent

Re: [sqlite] A crash bug in sqlite

On 12/9/19, Yongheng Chen wrote: > Hi, > > We found a crash bug in sqlite of master branch. Should now be fixed on trunk. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] A crash bug in sqlite

Yongheng Chen, on Monday, December 9, 2019 11:14 AM, wrote... > > So should we just report the bugs after another release version? We think the > sooner > the bugs get fixed, the better in terms of security, as this approach can > minimize > the number of bugs in future release. Yongheng,

Re: [sqlite] A crash bug in sqlite

I see. I totally agree with you. A better sqlite is what we all want. Best. Yongheng & Rui > On Dec 9, 2019, at 11:23 AM, Richard Hipp wrote: > > On 12/9/19, Yongheng Chen wrote: >> So should we just report the bugs after another release version? > > No. You should report problems as soon

Re: [sqlite] A crash bug in sqlite

On 12/9/19, Yongheng Chen wrote: > So should we just report the bugs after another release version? No. You should report problems as soon as you see them. That is why we have open-source. That is why all of our changes are out there in the open where anybody can see them - so that people

Re: [sqlite] A crash bug in sqlite

So should we just report the bugs after another release version? We think the sooner the bugs get fixed, the better in terms of security, as this approach can minimize the number of bugs in future release. > On Dec 9, 2019, at 10:56 AM, Jose Isaias Cabrera wrote: > > > Since no one

Re: [sqlite] A crash bug in sqlite

Since no one explains... ;-) Richard Hipp, on Monday, December 9, 2019 10:53 AM, wrote... > > On 12/9/19, Jose Isaias Cabrera, on > > Error: near "AS": syntax error > > > > So, I can't replicate your problem. thanks. > > You have to run off of the latest trunk version, as they are fuzzing > for

Re: [sqlite] A crash bug in sqlite

On 12/9/19, Jose Isaias Cabrera wrote: > Error: near "AS": syntax error > > So, I can't replicate your problem. thanks. You have to run off of the latest trunk version, as they are fuzzing for features that are unreleased. -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] A crash bug in sqlite

Yongheng Chen, on Monday, December 9, 2019 10:16 AM, wrote... > > Hi, > > We found a crash bug in sqlite of master branch. Here’s the POC > — > CREATE TABLE v0 ( v2 DOUBLE CHECK( ( v2 IN ( v2 , v1) ) ) , v1 UNIQUE AS( v2 > > v2 ) ) ; > INSERT INTO v0 VALUES ( 10 ); > SELECT v0 . v1 , v0 . v1

Re: [sqlite] Crash Bug Report

Thanks for the fix. > On Dec 9, 2019, at 9:43 AM, Richard Hipp wrote: > > On 12/8/19, Yongheng Chen wrote: >> >> We found one crash bug in sqlite, > > Simplified test case: > > CREATE TABLE t1(a); > CREATE VIEW v2(b) AS WITH t3 AS (SELECT b FROM v2) VALUES(1); > ALTER TABLE t1 RENAME TO t4;

Re: [sqlite] sqlite sync over network

thank you Jens,I have just found litesync (litesync - SQLite Replication and Synchronization) litesync seems to be a version of sqlite made by Ramos Bernardo from Brazil. | | | | litesync - SQLite Replication and Synchronization litesync makes easy to replicate and synchronize SQLite

[sqlite] A crash bug in sqlite

Hi, We found a crash bug in sqlite of master branch. Here’s the POC — CREATE TABLE v0 ( v2 DOUBLE CHECK( ( v2 IN ( v2 , v1) ) ) , v1 UNIQUE AS( v2 > v2 ) ) ; INSERT INTO v0 VALUES ( 10 ); SELECT v0 . v1 , v0 . v1 FROM v0 JOIN v0 USING ( v1 , v1) ; — The bug exists in "SQLite version 3.31.0

Re: [sqlite] Crash Bug Report

On 12/8/19, Yongheng Chen wrote: > > We found one crash bug in sqlite, Simplified test case: CREATE TABLE t1(a); CREATE VIEW v2(b) AS WITH t3 AS (SELECT b FROM v2) VALUES(1); ALTER TABLE t1 RENAME TO t4; Notice how the definition of the V2 view refers to itself. The ALTER TABLE command was

Re: [sqlite] Missed index opportunities with sorting?

Monday, December 09, 2019, 1:32:40 PM, Digital Dog wrote: > On Sat, Dec 7, 2019 at 3:50 AM Simon Slavin wrote: >> On 7 Dec 2019, at 2:26am, Shawn Wagner wrote: >> >> > The first one uses the index for all sorting, but the second one only >> uses it for sorting a, not b. I feel like the

Re: [sqlite] SLOW execution: Simple Query Uses More than 1 min

For reasons which you've described I'm a big fan of removing virtual memory from CPUs altogether. That would speed up things considerably. On Sun, Dec 8, 2019 at 6:43 PM James K. Lowden wrote: > On Sat, 7 Dec 2019 05:23:15 + > Simon Slavin wrote: > > > (Your operating system is allowed to

Re: [sqlite] Missed index opportunities with sorting?

On Sat, Dec 7, 2019 at 3:50 AM Simon Slavin wrote: > On 7 Dec 2019, at 2:26am, Shawn Wagner wrote: > > > The first one uses the index for all sorting, but the second one only > uses it for sorting a, not b. I feel like the descending sort could make > use of the index too, just reading the b