> "Mark Woodward" <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
