On Sun, Feb 9, 2020 at 11:46 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > "Nick Renders" <postg...@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?
