Author erlendaasland
Recipients berker.peksag, erlendaasland, serhiy.storchaka
Date 2021-05-19.09:53:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1621418019.57.0.388556259788.issue44079@roundup.psfhosted.org>
In-reply-to
Content
Yes, that seems to be the intention. But, I don't think there is a need to maintain the second list:

1. Resetting statements was historically needed both for commit and rollback; pending statements would block such operations. That's no longer the case for recent SQLite versions (commits fixed in SQLite 3.6.5, rollbacks in SQLite 3.7.11). The sqlite3 module no longer reset commit statements (6ed442c48dd7f8d3097e688a36bc027df3271621), and there should be no need to reset rollbacks either (see bpo-44092).
2. A statement with ref count zero will be garbage collected. Thus, of a statement is dropped from the LRU cache, it will be sqlite3_finalize'd. No statement, no problem. It's the same effect as if _pysqlite_drop_unused_statement_references() used the same limit as the LRU cache.

If we want to explicit reset statements (for some reason), we'd be better off to use sqlite3_stmt_next(). It's faster, and it covers _all_ statements for a given connection.
History
Date User Action Args
2021-05-19 09:53:39erlendaaslandsetrecipients: + erlendaasland, berker.peksag, serhiy.storchaka
2021-05-19 09:53:39erlendaaslandsetmessageid: <1621418019.57.0.388556259788.issue44079@roundup.psfhosted.org>
2021-05-19 09:53:39erlendaaslandlinkissue44079 messages
2021-05-19 09:53:39erlendaaslandcreate