Random crashes - segmentation fault

This is a copy of message sent to debian-user mailing list:

select version();
version
------------------------------------------------------------------------------------------------------------------
PostgreSQL 12.0 (Debian 12.0-1+b1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 9.2.1-8) 9.2.1 20190909, 64-bit

kjonca(at)poczta(dot)onet(dot)pl (Kamil Jońca) writes:

> It is home PC box with debian sid.
> Recently my postgres was upgraded from version 11 to 12.
> I migrate databases, and during last few days I have had 2 server
> crashes.
> Crashes were during different statements. And after crash these
> statements executed successfully.
> In log I have:
> ===============================================================
> 2019-11-04 00:07:38 CET LOG: server process (PID 19244) was terminated by signal 11: Segmentation fault
> 2019-11-04 00:07:38 CET DETAIL: Failed process was running: update queue set priority = -3 ;
> 2019-11-04 00:07:38 CET LOG: terminating any other active server processes
> [...]
> 2019-11-04 00:07:39 CET LOG: all server processes terminated; reinitializing
> 2019-11-04 00:07:39 CET DEBUG: mmap(150994944) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory
> 2019-11-04 00:07:39 CET LOG: database system was interrupted; last known up at 2019-11-04 00:02:24 CET
> ===============================================================
> 2019-11-05 21:43:56 CET LOG: server process (PID 23233) was terminated by signal 11: Segmentation fault
> 2019-11-05 21:43:56 CET DETAIL: Failed process was running: SELECT po_nr FROM get_free_numbers(999);
> 2019-11-05 21:43:56 CET LOG: terminating any other active server processes
> [...]
> 2019-11-05 21:43:57 CET LOG: all server processes terminated; reinitializing
> 2019-11-05 21:43:57 CET DEBUG: mmap(150994944) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory
> 2019-11-05 21:43:58 CET LOG: database system was interrupted; last known up at 2019-11-05 21:43:49 CET
> ===============================================================
>
> any hints?
>
> KJ

Today (13.XI.2019 - KJ) was another crash.
Another piece of a puzzle: There is (unlogged) table with 70M+
rows. After crash this table is empty (but table itself exists.)

KJ
--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
1.79 x 10^12 furlongs per fortnight -- it's not just a good idea, it's
the law!