On Mon, Nov 16, 2015 at 7:39 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Nov 15, 2015 at 1:12 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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. > > Oops. Committed. >
Thanks! > > 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. > > I don't understand this part. > The code in question is as below: tqueueReceiveSlot(TupleTableSlot *slot, DestReceiver *self) { .. if (tqueue->tupledesc != tupledesc || tqueue->remapinfo->natts != tupledesc->natts) { if (tqueue->remapinfo != NULL) pfree(tqueue->remapinfo); tqueue->remapinfo = BuildRemapInfo(tupledesc); } .. } Here the above check always passes as tqueue->tupledesc is not set due to which it always try to build remap info. Is there any reason for doing so? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com