AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 23 Bitcoin

sqldb+lncfg: use SQLite-appropriate default for max connections

Public commit record

What the developer wrote

Authored by ziggie

73/100 · Adequate
sqldb+lncfg: use SQLite-appropriate default for max connections

Both the sqldb and kvdb SQLite layers were not using a sensible default
for MaxConnections. The sqldb store used defaultMaxConns (25) which is
meant for Postgres, and the kvdb path passed 0 (unlimited) to
sqlbase.Init when unconfigured.

Add a MaxConns() method on SqliteConfig that returns the configured
value or defaults to 2, appropriate for SQLite's single-writer model.
Use it in both sqldb/sqlite.go and lncfg/db.go so both layers share
the same default.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a configuration bug where LND's SQLite database layers used an unsuitable number of maximum database connections. One layer used the Postgres default (25), and another used 0 (unlimited). The patch introduces a shared SQLite-specific default of 2 connections, which matches SQLite's single-writer design and reduces resource contention. This is a reliability/resource-tuning fix rather than a direct security vulnerability, though excessive connections could contribute to denial-of-service conditions under load.

Recommended action

Treat as a routine reliability/resource-optimization patch. Deploy in normal maintenance. Monitor for any SQLite busy-timeout or concurrency regressions if operators had previously relied on higher connection counts.

Security signals we found

01

Resource exhaustion mitigation: unlimited/25 SQLite connections could worsen contention and memory use

02

Configuration consistency fix across two SQLite database layers

03

No input validation, cryptographic, or authorization changes

04

No memory-unsafe code or pointer arithmetic

05

No explicit security boundary crossed

Risk score

Why this scored 23/100

Our methodology →
Potential impact 3/30
Exploitability 2/25
Stealth signal 2/15
Affected reach 5/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.