PostgreSQL 错误 DSA 内存分配请求大小无效。第 17 页配置

Question

迁移到 Postgres 17.2 2 周后，我们开始在一个查询上遇到错误，该查询在 Postgres 14 上完美运行了多年。我怀疑这可能与数据库或主要版本的配置参数有关，但理论上我们正在使用两个版本中都设置了默认值。 我们正在运行一个 64Gb 内存的 postgres RDS 实例，并且我们正在数据流中具有数千万条记录的表之间进行连接。我们设法将问题隔离到在索引列上执行 2 个常规外连接的查询。

SELECT *
FROM company
LEFT OUTER JOIN company_s
  ON company.domain = company_s.domain
LEFT OUTER JOIN socials
  ON company_s.raw_domain = socials.domain

此查询在 4 分钟内正常返回。但在本例中，它运行了 5 到 11 分钟，然后产生错误

invalid DSA memory alloc request size 1811939328

很奇怪的是，流程在前两周运行没有问题，然后在使用相同的数据时停止工作。

这出现在我们相同的暂存和生产环境中，在这两种情况下，实例都异常使用其所有内存（运行流程时通常有超过 10GB 的可用空间），但是在暂存中，它往往会在 11 分钟后失败，有时还会伴随

 SSL SYSCALL Error: EOF detected.

在生产中，它会在 5 分钟后失败：

invalid DSA memory alloc request size 1811939328

我们尝试了什么

1. 修剪过大的条目
2. 重建所有索引
3. 在所有涉及的表上运行

   analyze

4. 在仅 1MM 条目的缩减样本上运行是可行的，但这并不是我们问题的真正解决方案
5. 将shared_buffers增加到32GB

有一个错误报告，其错误与我们与 PG 17 相关的错误相同，但没有相关的解决方案信息 https://www.postgresql.org/message-id/18349-83d33dd3d0c855c3%40postgresql.org

有一些关于同一问题的问题，大部分没有答案或答案不适用于我们的问题

Answer 1

根据 PG17 上可能存在的错误报告，我们使用

运行查询

SET max_parallel_workers_per_gather = 0

这使得查询在 5 分钟内返回，没有错误。深入挖掘后，我们决定查看

work_mem

，RDS 默认将其设置为 4MB。我们根据这个参数guide松散地将配置中的这个值更新为64MB，并且它开始顺利工作，在大约3分钟内返回。

SET work_mem TO '16MB';