我看过类似的问题，但似乎没有一个能解决我的问题：
在Mac OS Siera 16GB RAM，本地主机上（没有其他Postgres在任何地方运行）
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
日志说：
2019-03-23 08：12：04.076 MDT [841]日志：服务器进程（PID 1175）被信号11终止：分段故障 2019-03-23 07：13：10.459 MDT [841]日志：终止任何其他活动 服务器进程2019-03-23 07：13：10.459 MDT [951]警告： 由于另一个服务器进程的崩溃而终止连接 2019-03-23 07：13：10.459 MDT [951]详细信息：邮政局长有 命令此服务器进程回滚当前事务，并 退出，因为另一个服务器进程异常退出并且可能退出了 共享内存损坏。 2019-03-23 07：13：10.459 MDT [951]提示：在 此时，您应该能够重新连接到数据库并重复执行 命令。 2019-03-23 07：13：10.460 MDT [980]致命：数据库系统 处于恢复模式2019-03-23 07：13：10.461 MDT [841]日志：所有服务器 进程终止；重新初始化2019-03-23 07：13：10.470 MDT [981] LOG：数据库系统被中断；最后一次了解是在2019-03-23 07:06:47 MDT 2019-03-23 07：13：10.744 MDT [981]日志：数据库系统 没有正确关闭；自动恢复进行中2019-03-23 07：13：10.746 MDT [981]日志：重做开始于28 / 15BF74F0 2019-03-23 07：13：10.746 MDT [981]日志：28 / 15BF7528处的记录长度无效： 想要24点，得到0 2019-03-23 07：13：10.746 MDT [981]日志：重做完成于 28 / 15BF74F0 2019-03-23 07：13：10.755 MDT [841]日志：数据库系统为 准备接受连接
PSQL版本：
psql --version
psql (PostgreSQL) 11.1
在psql终端和pgAdmin中都发生。发生这种情况时，不会出现CPU或内存峰值的情况。
在简单结果集上不会发生。参见此示例：这是相同的查询，第一次返回计数，第二次返回行（触发错误）：
shill=# with yards_manual as (
select device_id,loc, sum(sq_meters)*10.7639 as manual_yard_sq_ft from device d
inner join zones z on (z.device_id=d.id)
where z.enabled and z.sq_meters<46 or z.sq_meters>47
group by 1,2
)
select count(device_id) from yards_manual;
count
-------
84983
shill=# with yards_manual as (
shill(# select device_id,loc, sum(sq_meters)*10.7639 as manual_yard_sq_ft from device d
shill(# inner join zones z on (z.device_id=d.id)
shill(# where z.enabled and z.sq_meters<46 or z.sq_meters>47 --and z.crop_type in ('WARM_SEASON_GRASS','COOL_SEASON_GRASS')
shill(# group by 1,2
shill(# )
shill-#
shill-# select distinct device_id, y.manual_yard_sq_ft, build_area_ft2 , prop_area_ft2,(prop_area_ft2-build_area_ft2) as gis_yard_sq_ft2 --, st_npoints(property_geom) as corners
shill-# from yards_manual y inner join yards b on st_contains(b.property_geom,y.loc)
shill-# where (prop_area_ft2-build_area_ft2)>0 and (prop_area_ft2-build_area_ft2)<20000
shill-# ;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
尽管如此，最后一个查询有时会返回。一旦出错，它总是出错，直到我发送/停止数据库。但是，发送/停止并不总是有效。我尝试重新启动postgres，备份和还原数据库，都无济于事。问题刚刚开始发生。 VACCUUM FULL工作正常，错误仍然发生。数据库是24GB。
以下是同一查询，现在随机返回：
device_id | manual_yard_sq_ft | build_area_ft2 | prop_area_ft2 | gis_yard_sq_ft2
----------+-------------------+------------------+------------------+------------------
0022682e | 3999.9944068 | 1666.25757779497 | 12948.051385913 | 11281.793808118
002a4379 | 1934.99812741536 | 2907.60847006035 | 15872.352961764 | 12964.7444917037
002adeb4 | 1599.9984516096 | 2856.54321331877 | 9800.49184470172 | 6943.94863138295
但是当我第二次运行它时，它如上所述出错了。
这是SQL执行计划：
Unique (cost=137590686.48..137602981.21 rows=819649 width=548)
Output: y.device_id, y.manual_yard_sq_ft, b.build_area_ft2, b.prop_area_ft2, ((b.prop_area_ft2 - b.build_area_ft2))
CTE yards_manual
-> Finalize GroupAggregate (cost=163766.01..227836.10 rows=519752 width=77)
Output: z.device_id, d.loc, (sum(z.sq_meters) * '10.7639'::double precision)
Group Key: z.device_id, d.loc
-> Gather Merge (cost=163766.01..218090.75 rows=433126 width=77)
Output: z.device_id, d.loc, (PARTIAL sum(z.sq_meters))
Workers Planned: 2
-> Partial GroupAggregate (cost=162765.98..167097.24 rows=216563 width=77)
Output: z.device_id, d.loc, PARTIAL sum(z.sq_meters)
Group Key: z.device_id, d.loc
-> Sort (cost=162765.98..163307.39 rows=216563 width=77)
Output: z.device_id, d.loc, z.sq_meters
Sort Key: z.device_id, d.loc
-> Parallel Hash Join (cost=8564.46..133948.71 rows=216563 width=77)
Output: z.device_id, d.loc, z.sq_meters
Hash Cond: ((z.device_id)::text = (d.id)::text)
-> Parallel Seq Scan on public.zones z (cost=0.00..118450.79 rows=216563 width=45)
Output: z.device_id, z.sq_meters
Filter: ((z.enabled AND (z.sq_meters < '46'::double precision)) OR (z.sq_meters > '47'::double precision))
-> Parallel Hash (cost=5648.76..5648.76 rows=120376 width=69)
Output: d.loc, d.id
-> Parallel Seq Scan on public.device d (cost=0.00..5648.76 rows=120376 width=69)
Output: d.loc, d.id
-> Sort (cost=137362850.38..137364899.50 rows=819649 width=548)
Output: y.device_id, y.manual_yard_sq_ft, b.build_area_ft2, b.prop_area_ft2, ((b.prop_area_ft2 - b.build_area_ft2))
Sort Key: y.device_id, y.manual_yard_sq_ft, b.build_area_ft2, b.prop_area_ft2, ((b.prop_area_ft2 - b.build_area_ft2))
-> Nested Loop (cost=0.41..136878917.80 rows=819649 width=548)
Output: y.device_id, y.manual_yard_sq_ft, b.build_area_ft2, b.prop_area_ft2, (b.prop_area_ft2 - b.build_area_ft2)
-> CTE Scan on yards_manual y (cost=0.00..10395.04 rows=519752 width=556)
Output: y.device_id, y.loc, y.manual_yard_sq_ft
-> Index Scan using prop_geom_idx on public.yards b (cost=0.41..263.31 rows=2 width=173)
Output: b.block_id, b.property_geom, b.building_geom, b.prop_area_ft2, b.build_area_ft2, b.yard_area_ft, b.vegetation, b.yard_id
Index Cond: (b.property_geom ~ y.loc)
Filter: (((b.prop_area_ft2 - b.build_area_ft2) > '0'