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)
