Possible regressions in 3.44.x
(1) By anonymous on 2023-12-06 19:15:11 [link] [source]
Hi,
I am Carlos, one of the Tracker maintainers. I have noticed two regressions in SQLite 3.44.x, and it seems both are related to the same commit.
First, a testcase I've managed to condense:
begin transaction;
create table a(rowid, text);
insert into a VALUES(1, 'a');
drop table if exists fts;
drop view if exists v;
create view v as select rowid, text from a;
create virtual table fts_TMP using fts5(text, content='v');
insert into fts_TMP(rowid,text) select rowid, text from v;
alter table fts_TMP rename to fts;
insert into a VALUES(2, 'b');
insert into fts(rowid,text) VALUES (2, 'b');
insert into a VALUES(3, 'c');
insert into fts(rowid,text) VALUES (3, 'c');
drop table if exists fts;
drop view if exists v;
create view v as select rowid, text from a;
create virtual table fts_TMP using fts5(text, content='v');
insert into fts_TMP(rowid,text) select rowid, text from v;
alter table fts_TMP rename to fts;
commit;
Running this, I get:
⬢[carlos@toolbox ~]$ cat testcase.txt | sqlite3
Runtime error near line 19: SQL logic error
Runtime error near line 21: SQL logic error
Runtime error near line 22: SQL logic error
Parse error near line 23: no such table: fts_TMP
Parse error near line 24: no such table: fts_TMP
While this same SQL runs successfully with SQLite 3.43.x.
Bisecting through the git mirror, I see this is the responsible commit:
commit 71bae9f19f8c73841c0b4062af7c56bd83271e77
Author: dan <Dan Kennedy>
Date: Fri Oct 20 19:59:12 2023 +0000
Fix a problem allowing a COMMIT following an OOM to cause fts5 corruption.
FossilOrigin-Name: fba3129d1362dd3ee04d61cb3d3c48518cd98dde3febc85298f411776d60073e
As far as I could follow, the errors seem related to the renaming of the FTS table.
And the second regression: This commit also introduces a sqlite_exec()
in what seems to be a relatively hot path (the xSavepoint implementation). In my moderate stress tests involving FTS5 (perhaps smallish transactions are involved), this locally shows in Heaptrack/Sysprof flamegraphs as one of the most prominent single places where memory allocation operations are taking place.
(2) By Dan Kennedy (dan) on 2023-12-07 14:43:09 in reply to 1 [link] [source]
Thanks for reporting these two. Hopefully now fixed by this:
https://sqlite.org/src/vinfo/d8c6b246
Dan.
(3) By anonymous on 2023-12-07 21:15:12 in reply to 2 [source]
Carlos again here. Thank you for the quick fix! I checked with the SQLite git mirror and confirm your fixes make the Tracker test suite pass again.
(4) By Sam James (thesamesam) on 2023-12-09 14:28:25 in reply to 2 [link] [source]
That commit doesn't seem to apply cleanly to 3.44.2. Is there any chance I could trouble you for a backport? Many thanks.
(5) By Dan Kennedy (dan) on 2023-12-11 13:53:48 in reply to 4 [link] [source]
Missed this post earlier. It's now on the 3.44.* branch here:
https://sqlite.org/src/info/67da596d82ec0ed3
Cheers,
Dan.
(6) By Sam James (thesamesam) on 2023-12-12 05:43:52 in reply to 5 [link] [source]
Thanks a bunch Dan, I've pulled that in now for Gentoo!