"Nick Renders" <postgres@xxxxxxxxxx> 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. Still, since you can easily reproduce this, it'd be an idea to watch the doomed process in "top" and see how much memory and CPU it eats before dying. Also look into the system log and see if there are any relevant messages showing up there. As Adrian suggested, a stack trace would be useful too ... although, if this is being externally generated, it's likely that there's not any consistent spot where it happens. Also I'm not real sure that it's *possible* to get a stack trace from a SIGKILL. But if you can get one, try to collect three or so and see if they're consistent. Also, can you get an "EXPLAIN" of the query plan? (I imagine EXPLAIN ANALYZE would trigger the crash, though verifying that might be worth the time.) regards, tom lane
