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