Hi,

I just tested the "Support COPY TO for partitioned tables" patch. While tracing 
a normal case, I noticed this suspicious code:
```
        /*
         * If we are exporting partition data here, we check if converting 
tuples
         * to the root table's rowtype, because a partition might have column
         * order different than its root table.
         */
        if (root_rel != NULL)
        {
                root_slot = table_slot_create(root_rel, NULL);
                map = build_attrmap_by_name_if_req(RelationGetDescr(root_rel),  
 <<== input is root table
                                                                                
   RelationGetDescr(rel), <== output is partition
                                                                                
   false);
        }

        while (table_scan_getnextslot(scandesc, ForwardScanDirection, slot))
        {
                TupleTableSlot *copyslot;

                CHECK_FOR_INTERRUPTS();

                if (map != NULL)
                        copyslot = execute_attr_map_slot(map, slot, root_slot); 
<== input is partition, output is root table
                else
                {
                        /* Deconstruct the tuple */
                        slot_getallattrs(slot);
                        copyslot = slot;
                }
```

The code comment says that partition tuples should be converted to the root 
table's rowtype before output. Also, `execute_attr_map_slot()` takes the 
partition slot as input and the root slot as output. However, the attribute map 
is built in the opposite direction, with the root relation as input and the 
partition relation as output.

In normal cases, partitions have the same attribute list as the root table, so 
this bug is not triggered. I built the following repro by dropping a column 
from the partition, which makes the partition’s physical tuple descriptor 
different from the root table's descriptor:
```
evantest=# create table p (a int, b int) partition by range (a);
CREATE TABLE
evantest=# create table c (x int, a int, b int);
CREATE TABLE
evantest=# alter table c drop column x;
ALTER TABLE
evantest=# alter table p attach partition c for values from (1) to (10);
ALTER TABLE
evantest=# insert into p values (1, 11), (2, 22);
INSERT 0 2
evantest=# copy p to stdout;
\N      \N
\N      \N
```

As shown above, COPY incorrectly outputs all NULLs.

The fix is straightforward, just reverse the order of `rel` and `root_rel` when 
calling `build_attrmap_by_name_if_req()`. After the fix, COPY works correctly:
```
evantest=# copy p to stdout;
1       11
2       22
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/




Attachment: v1-0001-Fix-COPY-TO-attribute-mapping-for-partitioned-tab.patch
Description: Binary data

Reply via email to