[Bug Fix] : writing incorrect data to target Merge repartition Command

[paragikjain]

We were writing incorrect data to target collection in some cases of merge command. In case of repartition when source query it RELATION. We were referring to incorrect attribute number that was resulting into this incorrect behavior.

Example :

I have added fixed tests as part of this PR , Thanks.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 71.42857% with 2 lines in your changes missing coverage. Please review.

Project coverage is 52.71%. Comparing base (3c467e6) to head (92191f0).

:exclamation: There is a different number of reports uploaded between BASE (3c467e6) and HEAD (92191f0). Click for more details.

HEAD has 61 uploads less than BASE

Flag	BASE (3c467e6)	HEAD (92191f0)
14_regress_check-enterprise-failure	1	0
14_16_upgrade	1	0
14_15_upgrade	1	0
15_16_upgrade	1	0
16_regress_check-split	1	0
16_regress_check-enterprise-failure	1	0
16_regress_check-enterprise-isolation-logicalrep-2	1	0
14_regress_check-enterprise-isolation-logicalrep-1	1	0
14_regress_check-enterprise-isolation	1	0
15_regress_check-enterprise-isolation-logicalrep-1	1	0
15_regress_check-enterprise-failure	1	0
15_regress_check-operations	1	0
16_regress_check-enterprise-isolation-logicalrep-1	1	0
16_regress_check-vanilla	1	0
15_regress_check-multi-mx	1	0
16_regress_check-failure	1	0
16_regress_check-enterprise-isolation	1	0
15_regress_check-failure	1	0
14_regress_check-multi-mx	1	0
_upgrade	17	1
14_regress_check-vanilla	1	0
16_regress_check-enterprise	1	0
15_regress_check-enterprise	1	0
15_regress_check-vanilla	1	0
14_regress_check-split	1	0
14_regress_check-enterprise	1	0
14_regress_check-operations	1	0
16_regress_check-multi-1	1	0
15_regress_check-multi-1	1	0
14_regress_check-multi-1	1	0
16_regress_check-operations	1	0
15_regress_check-enterprise-isolation	1	0
14_regress_check-columnar	1	0
15_regress_check-enterprise-isolation-logicalrep-2	1	0
16_regress_check-columnar	1	0
15_regress_check-split	1	0
16_regress_check-multi	1	0
15_regress_check-multi	1	0
14_regress_check-isolation	1	0
15_regress_check-isolation	1	0
14_regress_check-failure	1	0
16_cdc_installcheck	1	0
15_cdc_installcheck	1	0
16_regress_check-multi-mx	1	0
16_regress_check-isolation	1	0
14_regress_check-multi	1	0

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #7659       +/-   ##
===========================================
- Coverage   89.70%   52.71%   -36.99%     
===========================================
  Files         283      283               
  Lines       60506    60481       -25     
  Branches     7539     7531        -8     
===========================================
- Hits        54276    31884    -22392     
- Misses       4073    25772    +21699     
- Partials     2157     2825      +668     

[tejeswarm]

Likely the problem is stemming from the fact that ConvertRelationRTEIntoSubquery() is really designed for

SELECT * FROM the relation

but in this case we are selecting column 1 and 3. May be we should change the function to handle

SELECT <col-list> FROM the relation

[tejeswarm]

I think I know what the problem is, can you please do me a small favor

Please change the below code

sourceResultsQuery->targetList =
                CreateAllTargetListForRelation(sourceRte->relid, requiredAttributes);

to

sourceResultsQuery->targetList =
                CreateFilteredTargetListForRelation(rteRelation->relid, requiredAttributes);

and see how things work

[paragikjain]

ou please do me

I think I know what the problem is, can you please do me a small favor

Please change the below code

sourceResultsQuery->targetList =
                CreateAllTargetListForRelation(sourceRte->relid, requiredAttributes);

to

sourceResultsQuery->targetList =
                CreateFilteredTargetListForRelation(rteRelation->relid, requiredAttributes);

and see how things work

Yes this works fine !! modified the changes with this function.