Re: [sqlite] [PATCH] Bug fix - Makefile.in: add extension 'BEXE' to prerequisite 'lemon' (for platforms with non-void BEXE)

On 12/25/19, Jannick wrote: > I hope sending to this list an email with the patch in the email body is OK. Tnx. Implemented at https://sqlite.org/src/info/f482a4cdfa768941 -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@m

Re: [sqlite] oserror-2.1.x fails when run on an BTRFS volume - directories may have any st_size.

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. On 12/25/19, Stefan Brüns wrote: > The oserror-2.1.1 test fails, as a exisiting te

Re: [sqlite] fts3corrupt4-33.0 depends on SQLITE_ENABLE_ICU

On 12/25/19, Stefan Brüns wrote: > The test added in https://www.sqlite.org/src/info/e01fdbf9f700e1bd > > requires icu to run successfully. Otherwise it errors out with: > > ! fts3corrupt4-33.0 expected: [1 {database disk image is malformed}] > ! fts3corrupt4-33.0 got: [1 {unknown tokenizer:

[sqlite] oserror-2.1.x fails when run on an BTRFS volume - directories may have any st_size.

The oserror-2.1.1 test fails, as a exisiting test.db-wal is silently ignored. Running this small example on e.g. XFS or tmpfs yields the following: $> mkdir test.db-wal $> strace -efile sqlite3 test.db ... sqlite> .databases openat(AT_FDCWD, "test.db", O_RDONLY) = -1 ENOENT (Datei oder Verzeichn

[sqlite] Misleading comment in various test/fts*.test files

In the various test files, there (in most cases) is a misleading comment. In i.e. fts3expr.test, the comment is inverted, in fts3fault2 it is correct: test/fts3expr.test:# If SQLITE_ENABLE_FTS3 is defined, omit this file. test/fts3expr.test-ifcapable !fts3 { -- test/fts3fault2.test:# If SQLITE_E

[sqlite] fts3corrupt4-33.0 depends on SQLITE_ENABLE_ICU

The test added in https://www.sqlite.org/src/info/e01fdbf9f700e1bd requires icu to run successfully. Otherwise it errors out with: ! fts3corrupt4-33.0 expected: [1 {database disk image is malformed}] ! fts3corrupt4-33.0 got: [1 {unknown tokenizer: icu}] Kind regards, Stefan -- Stefan Brü

Re: [sqlite] Causal profiling

On 12/25/19, Doug wrote: > Richard, can you please explain each of these? > > 1. API break > I wrote an application in Qt which uses SQLite. Therefore, I invoke SQLite > functions with some wrapper. For a 9% performance improvement in SQLite > using the direct call versus indirect call (as discuss

Re: [sqlite] Causal profiling

Richard, can you please explain each of these? 1. API break I wrote an application in Qt which uses SQLite. Therefore, I invoke SQLite functions with some wrapper. For a 9% performance improvement in SQLite using the direct call versus indirect call (as discussed in the talk), cannot the wrappe

Re: [sqlite] Causal profiling

On 12/25/19, sky5w...@gmail.com wrote: > Thanks for sharing! > Did his suggested optimization make it to a commit? No. That would be an API break, and would also render SQLite untestable. Furthermore, we have been unable to replicate the performance gains. -- D. Richard Hipp d...@sqlite.org __

Re: [sqlite] Causal profiling

Thanks for sharing! Did his suggested optimization make it to a commit? On Wed, Dec 25, 2019 at 10:46 AM Craig H Maynard wrote: > All, > > Just watched an interesting lecture by UMass professor Emery Berger on > improving software performance: > > https://www.youtube.com/watch?v=r-TLSBdHe1A > >

[sqlite] Causal profiling

All, Just watched an interesting lecture by UMass professor Emery Berger on improving software performance: https://www.youtube.com/watch?v=r-TLSBdHe1A SQLite is discussed in the section on causal profiling, which begins at 34:12. Craig -- Craig H Maynard Rhode Island, USA 401.413.2376 _

Re: [sqlite] When will the next version abaliable? Or any schedule available?

On 12/22/19, Ming Ding wrote: > We are using SQLite 3.30.1(which release in 2019-10-10) in our project now. > > But there are 5 security vulnerabilities published recently, > CVE-2019-19317,CVE > -2019-19244,CVE-2019-19603,CVE-2019-19645,CVE-2019-19646. We do not have an anticipated release date

[sqlite] When will the next version abaliable? Or any schedule available?

We are using SQLite 3.30.1(which release in 2019-10-10) in our project now. But there are 5 security vulnerabilities published recently, CVE-2019-19317,CVE -2019-19244,CVE-2019-19603,CVE-2019-19645,CVE-2019-19646. I found that both of them can be fixed by using the patch from github. I will appr

Re: [sqlite] CVE's opened on 3.30.1 status

On 12/25/19, Dominique Pellé wrote: > > According to https://sqlite.org/draft/releaselog/3_31_0.html > SQLite-3.31 is scheduled for 2019-12-31. > I have idea how accurate this date is though. :-) I made that estimate on 2019-10-29. Now that we are closer to the date, I can confidently predict t

Re: [sqlite] CVE's opened on 3.30.1 status

Raitses, Alex wrote: > Thanks a lot for the prompt response, > As far as I found in Fossil repository fixes for all CVE's , > excepting erroneously submitted CVE-2019-19646, were merged to Fossil. > Can you please estimate next official release of SQLite including these fixes? According to htt

Re: [sqlite] Long long int constants in sources

On Wed, 25 Dec 2019 at 01:24, Clemens Ladisch wrote: > Max Vlasov wrote: > > bcc 5.5 compiler ... didn't like long long constants > >such as -2251799813685248LL > > If you want to make this particular compiler happy, use > -2251799813685248i64. > Thanks, this helped when I tested this scenario.

[sqlite] [PATCH] Bug fix - Makefile.in: add extension 'BEXE' to prerequisite 'lemon' (for platforms with non-void BEXE)

I hope sending to this list an email with the patch in the email body is OK. Thanks, J. = diff --git a/Makefile.in b/Makefile.in index 015796b65..e4b824365 100644 --- a/Makefile.in +++ b/Makefile.in @@ -1177,7 +1177,7 @@ FTS5_SRC = \ $(TOP)/ext/fts5/fts5_varint.c \ $(TOP)/ext/fts