PSQL: прерывистая ошибка сегментации: сервер неожиданно закрыл соединение - PullRequest
Новая
       15

PSQL: прерывистая ошибка сегментации: сервер неожиданно закрыл соединение

0 голосов
/ 23 марта 2019

Я посмотрел на похожие вопросы, но ни один из них, похоже, не касался моего случая:

В Mac OS Siera 16 ГБ ОЗУ, localhost (другие постгрес не запущены где-либо) 

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] LOG: серверный процесс (PID 1175) был прерван по сигналу 11: ошибка сегментации 2019-03-23 ​​07:13:10.459 MDT [841] LOG: завершение любых других активных процессов сервера 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] FATAL: система базы данных находится в режиме восстановления. 2019-03-23 ​​07: 13: 10.461 MDT [841] LOG: все процессы сервера завершены;повторная инициализация 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] LOG: система базы данных не была корректно закрыта;выполняется автоматическое восстановление 2019-03-23 ​​07: 13: 10.746 MDT [981] LOG: повторный запуск начинается в 28 / 15BF74F0 2019-03-23 ​​07: 13: 10.746 MDT [981] LOG: неверная длина записи в 28 / 15BF7528:хотел 24, получил 0 2019-03-23 ​​07: 13: 10.746 MDT [981] LOG: повторение выполнено в 28 / 15BF74F0 2019-03-23 ​​07: 13: 10.755 MDT [841] LOG: система базы данных готова принимать соединения

Версия PSQL: 

psql --version
psql (PostgreSQL) 11.1

Происходит как в терминале psql, так и в pgAdmin.При этом не происходит скачков ЦП или памяти.

Это не происходит с простыми наборами результатов.Посмотрите на этот пример: это тот же запрос, первый раз возвращающий счетчик, второй раз возвращающий строки (что вызывает ошибку): 

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 работал нормально, ошибка все еще происходит.ДБ составляет 24 ГБ.

Вот тот же запрос, который теперь произвольно возвращается: 

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'
...