遥测表 llm_calls 无保留期与访问控制，全部租户正文无限期留存 #12

New Issue

2026-08-18T10:58:48+08:00

iomgaa commented

2026-08-18 10:58:48 +08:00

来源

issue #11 第 4 条。当时提出方明确说这条可以另开、不必与前三条绑在一起，前三条已随 1.2.0 之后的 tenant_id / meta 支持落地（见 CHANGELOG「未发布」段），这条一直没有承接的地方。

现状

llm_calls 存的是完整正文：messages 落库前只过 digest_messages，而它只对多模态 part 里的 image_url 做 sha256，纯文本原样透传（middleware/cache.py，写入点 middleware/telemetry.py）。response 同理。Embedding 路径有 200 字符上限（embedding.py），LLM 路径没有。

现在 tenant_id 已经是真实列，多租户下游可以挂 RLS 做读取隔离。但另外两件事仍是空白：

保留期：没有任何 TTL、归档或清理机制。库只管写入，写进去的行永久留存。
访问控制的默认状态：库不执行任何 GRANT/REVOKE，也不建议下游怎么分角色。默认状态是「任何能连库的账号都能读全部租户的全文」。

提出方的原话是：「无限期保留全部租户全文、且任何能连库的账号都能读」不应是默认状态。

为什么值得单独做

这不是性能问题，是合规面。表里是客户合同与标书全文，多租户混存。保留期缺失意味着删除请求（数据主体权利）无处执行；访问控制缺失意味着 RLS 只挡住了「用错租户上下文查询」，挡不住「用一个有全表权限的账号连上来」。

同时这件事与 #11 的不可逆性论证是同一类：数据一旦以当前形态写进去，事后再想补保留期，已经超期的那部分已经存在了。

可能的方向（未定，需要设计）

分区与保留：按 created_at 做 RANGE 分区、过期靠 DROP/DETACH 分区实现 O(1) 清理，而非 DELETE。pg_partman 可设 retention 自动化。这是审计表的通行做法。
正文的可选摘要化：给 LLM 路径也提供类似 embedding 的长度上限或摘要开关，让不需要全文的下游可以不存全文。注意这会与「审计链需要原始证据」冲突，是取舍不是改进。
访问控制：库不应代下游执行 DDL（与 #11 对 RLS 的边界结论一致），但可以在文档里给出角色划分模板（写入角色只 INSERT、报表角色只读且受 policy 约束）。
不可变性：审计表通行做法是 REVOKE UPDATE, DELETE + 触发器兜底，本表目前没有任何这类保护。

边界提示

按 #11 的结论，库自己执行不可逆的库级 DDL 是危险的（启用 RLS 而无 policy 是 default-deny，会静默击穿非多租户下游）。这条 issue 同样应当先明确「库做什么、下游 DBA 做什么」，再谈实现。

## 来源 issue #11 第 4 条。当时提出方明确说这条可以另开、不必与前三条绑在一起，前三条已随 1.2.0 之后的 `tenant_id` / `meta` 支持落地（见 CHANGELOG「未发布」段），这条一直没有承接的地方。 ## 现状 `llm_calls` 存的是**完整正文**：`messages` 落库前只过 `digest_messages`，而它只对多模态 part 里的 `image_url` 做 sha256，纯文本原样透传（`middleware/cache.py`，写入点 `middleware/telemetry.py`）。`response` 同理。Embedding 路径有 200 字符上限（`embedding.py`），LLM 路径没有。现在 `tenant_id` 已经是真实列，多租户下游可以挂 RLS 做读取隔离。但另外两件事仍是空白： 1. **保留期**：没有任何 TTL、归档或清理机制。库只管写入，写进去的行永久留存。 2. **访问控制的默认状态**：库不执行任何 `GRANT`/`REVOKE`，也不建议下游怎么分角色。默认状态是「任何能连库的账号都能读全部租户的全文」。提出方的原话是：「无限期保留全部租户全文、且任何能连库的账号都能读」不应是默认状态。 ## 为什么值得单独做这不是性能问题，是合规面。表里是客户合同与标书全文，多租户混存。保留期缺失意味着删除请求（数据主体权利）无处执行；访问控制缺失意味着 RLS 只挡住了「用错租户上下文查询」，挡不住「用一个有全表权限的账号连上来」。同时这件事**与 #11 的不可逆性论证是同一类**：数据一旦以当前形态写进去，事后再想补保留期，已经超期的那部分已经存在了。 ## 可能的方向（未定，需要设计） - 分区与保留：按 `created_at` 做 RANGE 分区、过期靠 `DROP`/`DETACH` 分区实现 O(1) 清理，而非 `DELETE`。`pg_partman` 可设 retention 自动化。这是审计表的通行做法。 - 正文的可选摘要化：给 LLM 路径也提供类似 embedding 的长度上限或摘要开关，让不需要全文的下游可以不存全文。注意这会与「审计链需要原始证据」冲突，是取舍不是改进。 - 访问控制：库不应代下游执行 DDL（与 #11 对 RLS 的边界结论一致），但可以在文档里给出角色划分模板（写入角色只 INSERT、报表角色只读且受 policy 约束）。 - 不可变性：审计表通行做法是 `REVOKE UPDATE, DELETE` + 触发器兜底，本表目前没有任何这类保护。 ## 边界提示按 #11 的结论，库自己执行不可逆的库级 DDL 是危险的（启用 RLS 而无 policy 是 default-deny，会静默击穿非多租户下游）。这条 issue 同样应当先明确「库做什么、下游 DBA 做什么」，再谈实现。