Re: PostgreSQL 8.0.6 crash

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Woodward <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostgreSQL 8.0.6 crash
Date: 2006-02-09 18:22:12
Message-ID: 20060209182212.GY4474@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> "Mark Woodward" <pgsql(at)mohawksoft(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2006-02-09 18:27:41 Re: [HACKERS] Krb5 & multiple DB connections
Previous Message Jim C. Nasby 2006-02-09 18:18:58 Re: streamlined standby procedure