Re: PostgreSQL 8.0.6 crash

From: "Mark Woodward" <pgsql(at)mohawksoft(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostgreSQL 8.0.6 crash
Date: 2006-02-09 18:28:25
Message-ID: 16528.24.91.171.78.1139509705.squirrel@mail.mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> "Mark Woodward" <pgsql(at)mohawksoft(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-02-09 18:39:57 Re: [HACKERS] Krb5 & multiple DB connections
Previous Message Stephen Frost 2006-02-09 18:27:41 Re: [HACKERS] Krb5 & multiple DB connections