No user-visible change, so I'm adding the skip news label.

Marking as draft until I've verified all the exit paths in _pysqlite_query_execute().

cc. @corona10

Marking as draft until I've verified all the exit paths in _pysqlite_query_execute().

I've left the exit paths as they are to avoid changing current behaviour. We can rework _pysqlite_query_execute later. There's much to do there :)

@pablogsal, are you comfortable with reviewing this, wrt. SQLite API? The change is very straight-forwared, so it should be easy to review.

Here's a link to the relevant API: https://sqlite.org/c3ref/stmt_busy.html

Do we have tests covering this behaviour from before?

Do we have tests covering this behaviour from before?

The if statement in query execute lacks test coverage. I've got one lying around from the sqlite3 coverage issue. I'll add it to the PR once I'm back at my computer. Thanks!

I would like to ame sure that we have coverage for this to ensure that we don't introduce regressions (although we shouldn't if I read this PR correctly).

I would like to ame sure that we have coverage for this to ensure that we don't introduce regressions (although we shouldn't if I read this PR correctly).

Of course.

BTW, I restored the optimisation of pysqlite_statement_reset: only call sqlite3_reset if needed. Calling it every time would acquire and release the SQLite mutex.

Putting this on hold until we've cleaned up sqlite3_reset usage: see #27844

#27844 is now merged; this PR is no longer on hold.

#27844 was reverted, so I'm putting this on hold again.

🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 37bf9ef 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

Buildbots are happy. I'll be merging this to main in a couple of days. This will not be backported.