* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> "Mark Woodward" <pgsql@mohawksoft.com> writes:
> > Again, regardless of OS used, hashagg will exceed "working memory" as
> > defined in postgresql.conf.
>
> So? If you've got OOM kill enabled, it can zap a process whether it's
> strictly adhered to work_mem or not. The OOM killer is entirely capable
> of choosing a victim process whose memory footprint hasn't changed
> materially since it started (eg, the postmaster).
Unless I've missed something here, disabling the OOM killer doesn't
really solve the problem here. What solves the problem is running
ANALYZE but it's still certainly the case that it would make some sense
for the Postmaster, upon realizing that it's gone well beyond its
work_mem boundary, to ideally switch plans to one which isn't going to
exceed its work_mem limit. Less ideally, it could give up and issue an
error to the user instead of running the box out of memory.
I appriciate that this is probably not very easy to implement but I
do believe the current situation could be improved in this regard.
Thanks,
Stephen
