You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We already have support for QUERY requests that modify the database, but the codepath that executes those requests assumes that all modifications are propagated to the WAL after the first call to sqlite3_step, which is not the case for a statement like DELETE FROM tab RETURNING col. Copying my comment from #472:
the "database changes occur during the first sqlite3_step" statement does not mean the changes will get flushed to the WAL at that point, they might remain in cache up until autocommit happens just before the sqlite3_step call that returns SQLITE_DONE. That makes things a bit difficult for us, since we want to VfsPoll and raft_apply before yielding any rows to the client. We could buffer all the rows up in memory, but that pretty much defeats the purpose of sending them to the client in batches. Alternatively, we could force a cache flush immediately after the first sqlite3_step.
The text was updated successfully, but these errors were encountered:
We already have support for QUERY requests that modify the database, but the codepath that executes those requests assumes that all modifications are propagated to the WAL after the first call to sqlite3_step, which is not the case for a statement like
DELETE FROM tab RETURNING col
. Copying my comment from #472:The text was updated successfully, but these errors were encountered: