Re: PostgreSQL 8.0.6 crash

On Feb 9, 2006, at 11:22 AM, Stephen Frost wrote:

> * 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.

So is the work_mem paramater that is set not strictly enforced?  Is  
it more like a suggestions as to what it SHOULD use and not a hard  
limit on how much memory the each process is ALLOWED to use?

If his work_mem is set to 1 mb and that process is using 500 mb for  
tasks that are supposed to stay in work_mem then doesn't that mean  
that that limit is not really a hard limit but rather a suggestion?

Rick