On Feb 9, 2006, at 11:22 AM, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
"Mark Woodward" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
