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.

Thanks for reporting these two. Hopefully now fixed by this:

https://sqlite.org/src/vinfo/d8c6b246

Dan.

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.

Missed this post earlier. It's now on the 3.44.* branch here:

https://sqlite.org/src/info/67da596d82ec0ed3

Cheers,

Dan.

Thanks a bunch Dan, I've pulled that in now for Gentoo!