db: don't actually create an explicit transaction for read commands.
What the developer wrote
Authored by Rusty Russell
db: don't actually create an explicit transaction for read commands.
Since we are the only writer, we don't need one.
Name (time in s) Min Max Mean StdDev Median
sqlite: test_spam_listcommands (before) 2.1193 2.4524 2.2343 0.1341 2.2229
sqlite: test_spam_listcommands (after) 2.0140 2.2349 2.1001 0.0893 2.0644
Postgres: test_spam_listcommands (before) 6.5572 6.8440 6.7067 0.1032 6.6967
Postgres: test_spam_listcommands (after) 4.4237 5.0024 4.6495 0.2278 4.6717
A nice 31% speedup!
Changelog-Changed: Postgres: significant speedup on read-only operations (e.g. 30% on empty SELECTs)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This is a performance optimization, not a security fix. The change removes an unnecessary explicit transaction wrapper around read-only database queries because the software is already the only writer to the database. The commit message and diff show only speed improvements and no security relevance.
No security action needed. Treat as a normal performance improvement during code review; verify that the single-writer assumption remains valid in the deployment context.
Security signals we found
No strong security signals were identified.
Evidence from the diff
In db/utils.c, db_query_prepared_canfail() no longer calls db_need_transaction() before executing read-only prepared statements. The commit rationale is that because Core Lightning is the sole writer, explicit transactions for reads are unnecessary. This is a single-line removal with performance benchmarks showing ~31% speedup on Postgres read-only operations. No security bug, vulnerability, or hardening is described or evident in the diff.
Changed components
db/utils.cdb_query_prepared_canfail()Inspect captured patch +0 / −1
diff --git a/db/utils.c b/db/utils.c
index 8c478189..d6234179 100644
--- a/db/utils.c
+++ b/db/utils.c
@@ -144,7 +144,6 @@ bool db_query_prepared_canfail(struct db_stmt *stmt)
assert(stmt->query->readonly);
trace_span_start("db_query_prepared", stmt);
trace_span_tag(stmt, "query", stmt->query->query);
- db_need_transaction(stmt->db, stmt->query->query);
ret = stmt->db->config->query_fn(stmt);
stmt->executed = true;
list_del_from(&stmt->db->pending_statements, &stmt->list);
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.