opsxsql

0 Fork 0

Files

T

History

opsx d6f27545ad fix(sqlite): DSN 加 busy_timeout/WAL/foreign_keys + 连接池上限，避免 database is locked

=== 背景：这是 opsxsql 的「死锁类」风险 ===
LokiStack 是自研 JsonDB + sync.RWMutex，问题是**锁重入死锁**（已由上游 2e97c04 修复）。
opsxsql 用 SQLite + GORM，风险形式不同但后果相似：
  裸 DSN（不带任何 pragma）+ 默认 journal 模式 + 无连接池上限
  → 写事务与读事务互相阻塞，并发写直接返回 "database is locked"(SQLITE_BUSY)，
    表现为「点保存失败 / 偶发 500」，而且不会挂住所以更难定位。

静态扫描结论：opsxsql 33 个 Go 文件无 RWMutex 重入问题（0 处），
唯一 RWMutex 在 internal/ghost 且用法正确。日志中 0 次 SQLITE_BUSY
（并发压力尚未到临界点，属**潜在**风险）。

=== 修改 1：DSN pragma ===
  ?_busy_timeout=5000   遇锁等 5 秒而不是立刻失败
  &_journal_mode=WAL    读写不互斥，写不阻塞读
  &_synchronous=NORMAL  WAL 下常规安全级别
  &_foreign_keys=on     SQLite 默认关闭外键，容易埋脏数据
仅在 DBPath 不含 "?" 时追加，保留运维自定义 DSN 的能力。

=== 修改 2：连接池上限 4 ===
SQLite 同时只允许一个写者，连接开太多只会加剧锁竞争。

=== 修改 3：ghost.go 回调移出锁（防御性）===
原来 cb(taskID, result.Output) 在持有 Manager.mu 写锁时执行；
若调用方在回调里查任务状态（GetTaskStatus 需要 RLock）会永久死锁。
当前所有调用方都传 nil，属潜在问题，一并修掉。

=== 实测（46a97a5c11b7，ns=sql）===
  Pod 1/1 Running，重启 0
  /app/data 出现 sqlite3.db-wal + sqlite3.db-shm  → WAL 已生效
  日志 0 次 database is locked / SQLITE_BUSY

2026-10-30 18:40:03 +00:00

cmd/server

fix(sqlite): DSN 加 busy_timeout/WAL/foreign_keys + 连接池上限，避免 database is locked

2026-10-30 18:40:03 +00:00

config

feat(backend): unified response helpers, refresh token, security hardening

2026-10-26 17:21:00 +08:00

internal

fix(sqlite): DSN 加 busy_timeout/WAL/foreign_keys + 连接池上限，避免 database is locked

2026-10-30 18:40:03 +00:00

router

feat(redis): 大 key 分页 + 流式导出（含票据鉴权）+ 查询行数上限默认 5000