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
