海量数据库是否支持 `FETCH ALL FROM '<unnamed portal 1>'`？

Question

在使用海量数据库（如OceanBase、TiDB或GaussDB等分布式NewSQL数据库）执行带游标的PL/pgSQL或兼容PostgreSQL协议的查询时，常遇到`FETCH ALL FROM ''`报错（如“portal not found”或“unsupported cursor operation”）。该问题源于：海量数据库多数不完全兼容PostgreSQL的隐式命名游标机制——``是PostgreSQL后端为隐式DECLARE生成的内部标识，而分布式架构下游标上下文难以跨节点一致维护，导致FETCH ALL无法定位或还原该未显式命名的portal。此外，部分海量数据库为优化资源调度，默认禁用或简化游标生命周期管理，仅支持显式DECLARE + FETCH NEXT/ABSOLUTE等受限操作。开发者若直接迁移PG应用，易因依赖此隐式行为而失败。如何识别当前海量数据库对匿名portal的支持程度？是否存在替代方案（如改用显式游标、流式结果集或分页查询）？这是典型兼容性与性能权衡的技术痛点。

Answer 1

```html

一、现象识别：从报错日志定位根本症结

当执行 FETCH ALL FROM '' 时，OceanBase（v4.3+）、TiDB（v7.5+）及 GaussDB(for openGauss) 均可能返回如下典型错误：

• ERROR: portal not found（OceanBase/TiDB 常见）
• ERROR: unsupported cursor operation（GaussDB 兼容模式下高频）
• ERROR: cursor '<unnamed>' does not exist（PostgreSQL 协议层透传错误）

这些并非网络或权限问题，而是协议解析阶段即失败——说明数据库服务端未在会话上下文中注册该隐式 portal。

二、兼容性测绘：三类NewSQL对匿名游标的支持矩阵

数据库	隐式 DECLARE 支持	FETCH ALL FROM ''	显式命名游标支持	游标超时默认值
OceanBase（MySQL/Oracle/Pg 模式）	仅 Pg 模式部分兼容（v4.3.2起实验性开启）	❌ 默认禁用（需 ob_enable_pg_implicit_cursor=ON）	✅ 完全支持（DECLARE c1 CURSOR FOR ...）	300s（可调）
TiDB（v7.5+ pg protocol mode）	❌ 不实现 backend-level implicit portal	❌ 永远报 portal not found	✅ 支持（但仅限 FETCH NEXT/FORWARD，不支持 FETCH ALL）	无自动清理（依赖客户端 close）
GaussDB(for openGauss 3.1+)	✅ 兼容 PG 14 行为（含 '' 解析）	⚠️ 仅当 cursor_tuple_fraction = 1.0 且非分布式执行计划下可用	✅ 推荐路径（支持 ABSOLUTE/RELATIVE/BINARY）	600s（受 cursor_timeout 控制）

三、诊断实践：四步法验证当前环境游标能力

1. 协议探针：使用 pg_isready -d "host=xxx port=xxx dbname=xxx options='-c cursor_tuple_fraction=1.0'" 验证参数可生效
2. 最小复现：

   BEGIN;
   DECLARE _c CURSOR FOR SELECT 1;
   FETCH ALL FROM '_c'; -- ✅ 显式名必通
   FETCH ALL FROM '';     -- ❌ 观察是否失败
   END;

3. 系统视图核查：查询 SELECT * FROM pg_cursors WHERE name = ''（GaussDB 可见；OceanBase/TiDB 返回空）
4. 驱动层日志：启用 JDBC 的 loggerLevel=TRACE&loggerFile=pgjdbc.log，捕获 PortalDescribe 消息是否被响应

四、替代方案全景图：按场景匹配迁移策略

graph LR
A[原始需求：逐行处理大数据集] --> B{数据规模 & 一致性要求}
B -->|≤ 10万行 & 强事务| C[显式命名游标 + FETCH NEXT 循环]
B -->|≥ 百万行 & 最终一致| D[Keyset 分页：WHERE id > ? ORDER BY id LIMIT N]
B -->|流式ETL & 无状态| E[Server-Side Prepared Statement + 无游标结果集]
B -->|跨节点聚合计算| F[物化中间结果表 + 分批 JOIN]
C --> G[适配成本低，但内存占用线性增长]
D --> H[性能最优，规避游标生命周期管理]
E --> I[JDBC 4.3+ 支持 setFetchSize(Integer.MIN_VALUE)]
F --> J[牺牲实时性，换取分布式稳定性]

五、生产级加固建议：五项必须落地的工程规范

• 禁止在应用代码中出现 FETCH ALL FROM '' 字面量，CI/CD 阶段通过 SQLLint 插件拦截
• 所有 PL/pgSQL 存储过程中的游标操作，强制前置 PERFORM pg_sleep(0); -- 触发portal注册校验
• 连接池配置中启用 preferQueryMode=simple（避免扩展协议触发隐式游标）
• 对 TiDB/OceanBase，统一抽象 CursorStream<T> 接口，内部封装分页重试与断点续取逻辑
• 监控大盘增加指标：pg_cursor_open_failures_total{db=~"oceanbase|tidb|gaussdb"}

分布式NewSQL的游标语义收敛仍需3–5年演进周期，当前阶段应以“显式契约优于隐式约定”为设计铁律。

```