Craig Ringer <ring...@ringerc.id.au> writes:
> OK, it's certainly leaking, but not in the same drastic way I was able
> to reproduce manually a couple of times earlier. Self-contained test
> case attached.
Using HEAD with stock parameters, I don't see any significant change in
allocated address space (VSZ): it sits right around 170MB. The reported
resident set size (RSS) starts from very little and rises to about
140MB, but I think that's just an artifact of the process touching more
and more of the shared-buffers array as it runs. The actual backend
memory consumption seems to be just a few meg.
I can get it to blow out memory if I set work_mem large enough to
persuade the planner to use hash aggregation (whereupon it tries to run
all the array_agg aggregates in parallel). However, that requires
work_mem set to a couple of GB, and I don't think it's really a bug when
the backend goes ahead and uses a couple of GB after I told it it could.
It's possible that the OP's problem boiled down to the planner making
a drastic underestimate of the number of GROUP BY groups, which could
mislead it into applying hash aggregation when there's not room; or
if the space used per aggregate was a lot more than the 8K that the
planner assumes when dealing with array_agg. But neither of those
errors seems to be happening in this example case.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
