ADBDEV-4345: Fix wrong allocation of writer slice in case of modifying shared CTE

[trexxet2]

Fix wrong allocation of writer slice in case of modifying shared CTE

Initially, when the CTE was first encountered, the create_ctescan_plan()
function constructed a subplan, and its slice was assigned the
GANGTYPE_PRIMARY_WRITER gang type. However, for subsequent occurrences of the
CTE, the subplan construction was bypassed. If these occurrences were located in
different slices and the CTE involved DML, their slices would sometimes be
assigned the GANGTYPE_PRIMARY_WRITER gang type. This lead to issues when the
ShareInputScans were assigned producer and consumer roles by the
apply_shareinput_dag_to_tree(), which uses a specific tree traversal order, and
in some cases, there was a scenario when the consumer was assigned to a
GANGTYPE_PRIMARY_WRITER slice, while the producer was placed in a
GANGTYPE_PRIMARY_READER slice, resulting in an execution error when the reader
gang attempted to execute a ModifyTable node.

To resolve this issue, the patch introduces a check for the gang type of
root->curSlice when creating the shared plan for the first time. If the gang
type has changed compared to its previous value during planning, the
ShareInputScan is marked as a writer slice maker by setting the
rootSliceIsWriter flag to true. This state is also applied to all subsequent
occurrences of the CTE. After assigning consumer and producer roles to each
ShareInputScan, the correct gang type is set for the producer
(GANGTYPE_PRIMARY_WRITER) and for the consumers (GANGTYPE_PRIMARY_READER, if the
consumer is in a different slice from the producer) within the
shareinput_mutator_xslice_2() function. This ensures that the gang type is
correctly assigned, preventing the execution error encountered in the original
scenario.

Co-authored-by: Alexander Kondakov <a.kondakov@arenadata.io>

[bimboterminator1]

Why does analyze show never executed?

Probably because of the portal strategy:
#557

[bandetto]

Why does analyze show never executed?

EXPLAIN (ANALYZE, SLICETABLE)
WITH cte AS (
        INSERT INTO with_test VALUES (1) RETURNING *
)
SELECT i FROM cte;
                                                      QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
 Gather Motion 1:1  (slice1; segments: 1)  (cost=0.00..0.07 rows=3 width=4) (actual time=9.510..9.514 rows=1 loops=1)
   ->  Insert on with_test  (cost=0.00..0.03 rows=1 width=4) (never executed)
         ->  Result  (cost=0.00..0.01 rows=1 width=4) (never executed)
 Optimizer: Postgres-based planner
 Planning Time: 5.980 ms
 Slice 0: Dispatcher; root 0; parent -1; gang size 0
 Slice 1: Primary Writer; root 0; parent 0; gang size 1
   (slice0)    Executor memory: 36K bytes.
   (slice1)    
 Memory used:  128000kB
 Execution Time: 10.138 ms
(11 rows)

(never executed) shows up even without the patch on working DML queries. With diff:

diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c
index 251860682e..48b17d4ded 100644
--- a/src/backend/tcop/pquery.c
+++ b/src/backend/tcop/pquery.c
@@ -375,10 +375,12 @@ ChoosePortalStrategy(List *stmts)
 					pstmt->copyIntoClause == NULL &&
 					pstmt->refreshClause == NULL)
 				{
-					if (pstmt->hasModifyingCTE)
-						return PORTAL_ONE_MOD_WITH;
-					else
+					if (!pstmt->hasModifyingCTE)
 						return PORTAL_ONE_SELECT;
+					else if (Gp_role != GP_ROLE_EXECUTE)
+						return PORTAL_ONE_MOD_WITH;
+
+					return PORTAL_MULTI_QUERY;
 				}
 				if (pstmt->commandType == CMD_UTILITY)
 				{

Stats are back:

EXPLAIN (ANALYZE, SLICETABLE)
WITH cte AS (
        INSERT INTO with_test VALUES (1) RETURNING *
)
SELECT i FROM cte;
                                                      QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
 Gather Motion 1:1  (slice1; segments: 1)  (cost=0.00..0.07 rows=3 width=4) (actual time=2.382..2.386 rows=1 loops=1)
   ->  Insert on with_test  (cost=0.00..0.03 rows=1 width=4) (actual time=0.213..0.214 rows=1 loops=1)
         ->  Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.012..0.012 rows=1 loops=1)
 Optimizer: Postgres-based planner
 Planning Time: 26.801 ms
 Slice 0: Dispatcher; root 0; parent -1; gang size 0
 Slice 1: Primary Writer; root 0; parent 0; gang size 1
   (slice0)    Executor memory: 36K bytes.
   (slice1)    Executor memory: 38K bytes (seg1).
 Memory used:  128000kB
 Execution Time: 3.348 ms
(11 rows)

Please look at this patch:

Probably because of the portal strategy:
#557