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

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HAWQ-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222020#comment-15222020 ] 

ASF GitHub Bot commented on HAWQ-621:
-------------------------------------

GitHub user foyzur opened a pull request:

    https://github.com/apache/incubator-hawq/pull/549

    HAWQ-621. Fixing tuple descriptor leak in split_rows during an ALTER TABLE SPLIT PARTITION. 

    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.
    
    
    Solution:
    -----------
    
    Following the call path of split_rows, the method split_rows() is only called from 
    
    ```
    split_rows(Relation, Relation, Relation) : void
    	ATPExecPartSplit(Relation *, AlterPartitionCmd *) : void
    		ATExecCmd(List * *, AlteredTableInfo *, Relation *, AlterTableCmd *) : void
    			ATPExecPartAlter(List * *, AlteredTableInfo *, Relation, AlterPartitionCmd *) : void
    			ATRewriteCatalogs(List * *) : void
    ```
    
    By the time we call split_rows, we know precisely the two relation where we will be inserting into. We create ResultRelInfo for both of these relations (the two target relations) at the beginning of split_rows(), called rria, and rrib. Both of these ResultRelInfo only have lifespan of the containing method split_rows(). We use the ri_resultSlot of these two rria and rrib to cache the TupleTableSlot inside reconstructMatchingTupleSlot() where we create additional TupleTableSlot using the tuple descriptors of the two target relations, therefore pinning these two target relation's TupleDesc. As the rria and rrib only live during split_rows() and only used for all the tuples in ONE CALL of split_rows(), we can easily drop the additional TupleTableSlot ri_resultSlot of both rria and rrib, and that will also unpin underlying TupleDesc.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/foyzur/incubator-hawq tupledesc

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-hawq/pull/549.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #549
    
----
commit 88085577d226efb60b4c1e8ecdec6187816c8f1e
Author: Foyzur Rahman <fo...@gmail.com>
Date:   2016-03-22T01:11:13Z

    HAWQ-621. Fixing tuple descriptor leak in split_rows during an ALTER TABLE SPLIT PARTITION.

----


> 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)