> "Mark Woodward" <pgsql@mohawksoft.com> writes:
>> I think it is still a bug. While it may manifest itself as a pg crash on
>> Linux because of a feature with which you have issue, the fact remains
>> that PG is exeeding its working memory limit.
>
> The problem is that *we have no way to know what that limit is* ---
> short of exceeding it and being summarily killed. (BTW, the kernel
> doesn't know what the limit is either.) There is simply not any way
> to operate robustly under the OOM-kill regime.
No, you misunderstand what I said, the "working memory" as defined in
postgresql.conf. I don't care about the OS debate.
>
> While I'll certainly acknowledge that it'd be nice if hashagg had
> spill-to-disk capability, that wouldn't alter the fundamental fact that
> if you want reliable behavior you MUST turn off OOM kill. There is not
> anything we can do at the database level to work around that kernel-level
> misdesign.
Again, regardless of OS used, hashagg will exceed "working memory" as
defined in postgresql.conf.
At issue is would a lack of ANALYZE justify this behavior? If so, it
should be documented.
