Tiger Geocoder使用时PostgreSQL出现SSL SYSCALL错误与信号11段错误问题

故障原因定位 #

• 架构兼容缺陷：你使用的r6g是AWS Graviton2 ARM架构处理器，PostgreSQL 12的早期小版本、配套的PostGIS扩展对ARM架构的内存访问逻辑适配不完善，Tiger Geocoder处理复杂地址匹配时很容易触发内存越界，直接抛出signal 11段错误。
• 配置参数不适配：pgtune生成的是x86架构下的通用配置，两个关键参数不符合你的场景：一是work_mem仅40MB，Tiger Geocoder的多表关联排序查询对临时内存要求极高，复杂地址查询时内存分配不足会触发边界溢出；二是shared_buffers配置为32GB，占r6g.4xlarge总内存的25%，ARM架构下PostgreSQL的shared_buffers内存回收逻辑和x86存在差异，过高占比会触发内核内存页异常。
• 数据集与查询逻辑冲突：2019版Tiger Geocoder的部分区域拓扑数据存在非法值，查询到这类数据时会触发PostGIS坐标计算逻辑异常，直接导致PostgreSQL主进程崩溃。
• 并行查询冲突：Tiger Geocoder的地址匹配逻辑没有做并行查询适配，多worker并行执行时会出现内存访问冲突，触发段错误。

解决方案 #

快速验证方案 #

先确认问题根源，执行以下操作：
在触发崩溃的地址查询前，先执行SQL SET max_parallel_workers_per_gather = 0; 关闭当前会话的并行查询，再执行地址编码请求，如果不再崩溃说明是并行查询冲突导致的问题。

永久修复方案 #

1. 升级组件版本
   • 将PostgreSQL 12升级到12.12及以上的最新小版本，该版本修复了Graviton2架构下的多个内存访问缺陷
   • 升级PostGIS到3.2及以上版本，同步升级Tiger Geocoder扩展，修复地址匹配逻辑中的已知段错误问题
2. 调整postgresql.conf配置

   work_mem = 131072kB  # 提升到128MB，满足复杂地址排序的内存需求
   shared_buffers = 24GB  # 降低至总内存的18%，适配ARM架构内存管理逻辑
   max_parallel_workers_per_gather = 0  # 关闭并行查询，避免冲突
   

   配置修改后重启PostgreSQL服务生效
3. 修复数据集异常
   • 执行SQL SELECT tiger.loader_verify_census('2019'); 校验2019版Tiger数据集的异常
   • 对触发崩溃的地址对应的行政州，重新加载对应州的Tiger数据包，修复单州数据损坏问题

内容的提问来源于stack exchange，提问作者S A R