Npgsql COPY 导出报二进制签名错误，先检查超长 NOTICE

COPY 导出本来能运行，函数多输出一段 NOTICE 后，BeginBinaryExport 却报 Invalid COPY binary signature at beginning!；文本导出也可能没有内容，最后等到 Command Timeout。先查看这次 COPY 查询调用的函数、触发器或扩展是否产生了很长的通知。

在已确认的路径中，通知大于读缓冲区后，连接会分配更大的缓冲；导出器仍持有创建时的旧缓冲引用。随后读取位置错开，可能把协议消息当成 COPY 数据。异常中的“签名不正确”因此不一定表示表中有坏二进制字段。

先保护未完成的导出结果

不要把已经写出一些字节的文件标记为成功，也不要继续在异常连接上发查询来“对齐”协议。保留失败文件、导出范围、驱动版本及错误顺序，按应用原来的释放流程关闭导出器和连接。重试前明确输出目标的替换或断点策略，避免把两次结果直接追加到一起。

Npgsql 10.0.3 正式源码中，raw COPY 流和 binary exporter 都会缓存初始读缓冲；连接读取超大非 CopyData 消息时可能替换它。具体故障仍须结合通知大小和执行路径判断，单凭一个 COPY 超时不能认定就是这个问题。

在本次会话内减少已确认的通知

若通知来自自己可控制的查询函数，优先避免为每行构造巨大的 NOTICE，保留必要诊断到原有日志渠道。忽略客户端 Notice 事件处理器不够，消息到达驱动后仍需解析。

对于不依赖 NOTICE 的受控导出，可以在同一连接的事务内，先单独执行下面这条命令，再通过原 COPY API 导出：

SET LOCAL client_min_messages = warning;

这要求连接已经处于事务中。不要把 SET 与 COPY 拼成一条字符串传入 BeginBinaryExport；COPY API 对命令和协议有自己的要求。原事务的提交、回滚和快照一致性仍按应用方案处理。SET LOCAL 到事务结束即恢复，不必改服务器全局配置。

只有确认可以不接收较低级别通知时才采用它。WARNING 和 ERROR 仍需处理；这个设置不能保护所有可能导致缓冲切换的大消息，也不是驱动修复。若通知承担业务信号，应先设计保留渠道，不能无声丢弃。

验证内容完整，而不只看命令结束

用包含原触发函数的受控数据分别检查普通通知和原来的超长通知场景，核对文本或二进制输出的格式、记录数、关键字段与校验结果。再检查异常、取消以及输出文件未完成时的恢复路径，确认没有把半份结果交给下游。

增大 Read Buffer Size 只有在消息大小确实有界时才可能暂时避开该条件，并会改变每连接内存占用；不能无限增大来替代消息控制。升级则应确认对应正式版本修复了这条缓冲引用路径，再以同一导出案例复查，不能因连接重新可用就宣称数据完整性已恢复。