On Sun, Feb 9, 2020 at 11:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Nick Renders" <postgres@arcict.com> writes:
> > When we do the following statement:
> > SELECT * FROM f_gsxws_schedule WHERE UPPER(gwsc_dossier) = 'TEST'
> > the Postgres service restarts.
>
> Hm.
>
> > Here is what is logged:
> > 2020-02-08 20:21:19.942 CET [83892] LOG: server process (PID 85456) was
> > terminated by signal 9: Killed: 9
> > 2020-02-08 20:21:19.942 CET [83892] DETAIL: Failed process was running:
> > SELECT * FROM f_gsxws_schedule WHERE UPPER(gwsc_dossier) = 'TEST'
>
> That's mighty interesting, because signal 9 is an external SIGKILL,
> not an internal-to-Postgres software fault.
>
> If you were running on Linux I would hypothesize that your process
> was getting killed by the infamous OOM killer, in which case we could
> guess that for some reason this query is consuming an unreasonable
> amount of memory and thereby attracting the wrath of the OOM killer.
> However, I'm not aware that any such mechanism exists on macOS.
macOS's thing like that appears as "kernel[0]: memorystatus_thread:
idle exiting pid XXX [some program]" in system.log, which seems like a
bit of an understatement to me but that's what they call it. Some
details here:
http://newosxbook.com/articles/MemoryPressure.html
Nick, did you see that?