关闭产品级最大行数限制#3003
Conversation
t8y2
left a comment
There was a problem hiding this comment.
这块我先 request changes,主要是 CI 现在已经红了。
packages/app-tests/settingsStore.test.ts:47 还在验证保存的 pageSize: 200000 会被归一化到 100000,但这次改动后会直接返回 200000。如果去掉 100,000 上限是预期行为,需要同步更新这个测试和对应的行为约定;如果不是预期,就需要恢复归一化里的上限保护。
另外顺手把注释掉的 import/constant 删除掉,并把 docs/performance/memory-usage-audit.md 里相邻两条互相冲突的建议合并一下会更干净。修完后我再 review 一下。
|
已完成全部修改:
|
t8y2
left a comment
There was a problem hiding this comment.
request changes: 上次提到的 CI 和测试问题已经修复,但目前还有两个正确性问题。
-
Agent 游标路径只传了
pageSize/fetchSize,没有传maxRows。agent_execute_query_page_params因此仍使用固定的MAX_ROWS = 10000,所以 JDBC、Presto 等 Agent/External 驱动即使设置 200000,结果集仍会在 10000 行处被关闭。请让该路径的maxRows至少与请求的pageSize一致,并补一个超过 10000 行的 Agent 分页回归测试。 -
normalizeResultPageSize现在接受任意有限正数,但 Agent 协议最终通过 GsongetAsInt()读取。超过 Javaint范围的值会静默溢出,例如2147483648会变成负数,随后被当成一行分页处理。请保留一个与前后端类型和内存模型兼容的明确上限,并在前端归一化及后端边界同时校验。
t8y2
left a comment
There was a problem hiding this comment.
Request changes: the two correctness issues from the previous review remain unchanged after the latest merge from main.
-
The Agent cursor request sends
pageSizeandfetchSizebut notmaxRows.agent_execute_query_page_paramstherefore falls back to the fixed 10,000-row safety limit, so JDBC/Presto/other Agent drivers still close the result session at 10,000 rows even when the configured page size is larger. -
Removing every upper bound allows values above Java's signed
intrange to reach the Agent protocol. GsongetAsInt()silently wraps2147483648to-2147483648; the resulting negative page size is then normalized into incorrect pagination behavior.
Please pass a compatible maxRows for Agent paging, keep an explicit cross-runtime upper bound, validate it at both boundaries, and add regression tests above 10,000 rows and around the Java int limit.
变更说明
关闭了对
MAX_RESULT_PAGE_SIZE做产品级收紧。当前最大可到 100,000 行,配合宽表和 DataGrid 派生数组会非常容易冲高内存的建议,有用户自定义设置可显示多少行变更类型
涉及前端
验证
编写sql查询后第一次查询10万行,在分页出设置999999,再次查询可正常查询出数据。
make check通过make cargo-check-fast通过关联 Issue
Close #2478