You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hawq.apache.org by "Foyzur Rahman (JIRA)" <ji...@apache.org> on 2016/04/01 19:15:25 UTC

[jira] [Created] (HAWQ-621) TupleDescriptor leak during split_partition

Foyzur Rahman created HAWQ-621:
----------------------------------

             Summary: TupleDescriptor leak during split_partition
                 Key: HAWQ-621
                 URL: https://issues.apache.org/jira/browse/HAWQ-621
             Project: Apache HAWQ
          Issue Type: Bug
          Components: Query Execution
            Reporter: Foyzur Rahman
            Assignee: George Caragea


During split_rows, we may create new tuple table slot inside reconstructMatchingTupleSlot() if the descriptor of the new target relation does not match the source relation. We then cache this slot inside the target relation's ri_resultSlot. This process pins the tuple descriptor of the new target relation. However, at the end of split_rows, when we are finished with this "cached" tuple table slot, we don't free them. This results in a WARNING that we leaked a tuple descriptor.

Repro:

{code}
-- Test for tuple descriptor leak during row splitting
DROP TABLE IF EXISTS split_tupdesc_leak;
CREATE TABLE split_tupdesc_leak
(
   ym character varying(6) NOT NULL,
   suid character varying(50) NOT NULL,
   genre_ids character varying(20)[]
) 
WITH (APPENDONLY=true, ORIENTATION=row, COMPRESSTYPE=zlib, OIDS=FALSE)
DISTRIBUTED BY (suid)
PARTITION BY LIST(ym)
(
	DEFAULT PARTITION p_split_tupdesc_leak_ym  WITH (appendonly=true, orientation=row, compresstype=zlib)
);

INSERT INTO split_tupdesc_leak VALUES ('201412','0001EC1TPEvT5SaJKIR5yYXlFQ7tS','{0}');

ALTER TABLE split_tupdesc_leak SPLIT DEFAULT PARTITION AT ('201412')
	INTO (PARTITION p_split_tupdesc_leak_ym, PARTITION p_split_tupdesc_leak_ym_201412);

DROP TABLE split_tupdesc_leak;
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)