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)