On Fri, Nov 13, 2015 at 11:05 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > > On Wed, Nov 11, 2015 at 6:53 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > > > I've committed most of this, except for some planner bits that I > > didn't like, and after a bunch of cleanup. Instead, I committed the > > consider-parallel-v2.patch with some additional planner bits to make > > up for the ones I removed from your patch. So, now we have parallel > > sequential scan! > > Pretty cool. All I had to do is mark my slow plperl functions as > being parallel safe, and bang, parallel execution of them for seq > scans. > > But, there does seem to be a memory leak. >
Thanks for the report.
I think main reason of the leak in workers seems to be due the reason
that one of the buffer used while sending tuples (in function BuildRemapInfo)
from worker to master is not getting freed and it is allocated for each
tuple worker sends back to master. I couldn't find use of such a buffer,
so I think we can avoid the allocation of same or atleast we need to free
it. Attached patch remove_unused_buf_allocation_v1.patch should fix the
issue.
Another thing I have noticed is that we need to build the remap info
target list contains record type of attrs, so ideally it should not even go in
this path when such attrs are not present. The reason for the same was
that the tuple descriptor stored in TQueueDestReceiver was not updated,
attached patch fix_initialization_tdesc_v1 fixes this issue.