File tree Expand file tree Collapse file tree 4 files changed +90
-0
lines changed
singlenode_isolation2/expected/gdd Expand file tree Collapse file tree 4 files changed +90
-0
lines changed Original file line number Diff line number Diff line change @@ -1454,6 +1454,25 @@ ldelete:;
1454
1454
ereport (ERROR ,
1455
1455
(errcode (ERRCODE_T_R_SERIALIZATION_FAILURE ),
1456
1456
errmsg ("could not serialize access due to concurrent delete" )));
1457
+
1458
+ /*
1459
+ * If DELETE operator is generated by SplitUpdate node (SplitUpdate
1460
+ * node is generated for updating the partition keys), we raise an error.
1461
+ *
1462
+ * The root cause is SplitUpdate will split the origin tuple
1463
+ * to two tuples, one is for deleting and the other one
1464
+ * is for inserting. we can skip the deleting tuple if we
1465
+ * found the tuple is updated concurrently by another
1466
+ * transaction, but it is difficult to skip the inserting
1467
+ * tuple, so it will leads to more tuples after updating.
1468
+ */
1469
+ if (splitUpdate )
1470
+ {
1471
+ ereport (ERROR ,
1472
+ (errcode (ERRCODE_IN_FAILED_SQL_TRANSACTION ),
1473
+ errmsg ("could not split update tuple which has been deleted by other transaction" )));
1474
+ }
1475
+
1457
1476
/* tuple already deleted; nothing to do */
1458
1477
return NULL ;
1459
1478
Original file line number Diff line number Diff line change @@ -240,6 +240,33 @@ DROP
240
240
DROP
241
241
0q: ... <quitting>
242
242
243
+ -- test ORCA partition table
244
+ create table test(a int, b int, c int) partition by range(b) (start (1) end (7) every (3));
245
+ CREATE
246
+ insert into test values (1, 1, 1);
247
+ INSERT 1
248
+ 1: begin;
249
+ BEGIN
250
+ 1: delete from test where b = 1;
251
+ DELETE 1
252
+ -- in session 2, in case of ORCA DML invokes EPQ
253
+ -- the following SQL will hang due to XID lock
254
+ 2&: update test set b = 1; <waiting ...>
255
+ 1: end;
256
+ END
257
+ 2<: <... completed>
258
+ UPDATE 0
259
+
260
+ 0: select * from test;
261
+ a | b | c
262
+ ---+---+---
263
+ (0 rows)
264
+ 0: drop table test;
265
+ DROP
266
+ 0q: ... <quitting>
267
+ 1q: ... <quitting>
268
+ 2q: ... <quitting>
269
+
243
270
-- split update is to implement updating on hash keys,
244
271
-- it deletes the tuple and insert a new tuple in a
245
272
-- new segment, so it is not easy for other transaction
Original file line number Diff line number Diff line change @@ -129,6 +129,23 @@ DROP TABLE t_concurrent_update;
129
129
0 : drop table tab_update_epq2 ;
130
130
0q:
131
131
132
+ -- test ORCA partition table
133
+ create table test (a int , b int , c int ) partition by range(b) (start (1 ) end (7 ) every (3 ));
134
+ insert into test values (1 , 1 , 1 );
135
+ 1 : begin ;
136
+ 1 : delete from test where b = 1 ;
137
+ -- in session 2, in case of ORCA DML invokes EPQ
138
+ -- the following SQL will hang due to XID lock
139
+ 2 &: update test set b = 1 ;
140
+ 1 : end;
141
+ 2 < :
142
+
143
+ 0 : select * from test;
144
+ 0 : drop table test ;
145
+ 0q:
146
+ 1q:
147
+ 2q:
148
+
132
149
-- split update is to implement updating on hash keys,
133
150
-- it deletes the tuple and insert a new tuple in a
134
151
-- new segment, so it is not easy for other transaction
Original file line number Diff line number Diff line change @@ -240,6 +240,33 @@ DROP
240
240
DROP
241
241
0q: ... <quitting>
242
242
243
+ -- test ORCA partition table
244
+ create table test(a int, b int, c int) partition by range(b) (start (1) end (7) every (3));
245
+ CREATE
246
+ insert into test values (1, 1, 1);
247
+ INSERT 1
248
+ 1: begin;
249
+ BEGIN
250
+ 1: delete from test where b = 1;
251
+ DELETE 1
252
+ -- in session 2, in case of ORCA DML invokes EPQ
253
+ -- the following SQL will hang due to XID lock
254
+ 2&: update test set b = 1; <waiting ...>
255
+ 1: end;
256
+ END
257
+ 2<: <... completed>
258
+ ERROR: could not split update tuple which has been deleted by other transaction (seg1 127.0.0.1:7003 pid=22726)
259
+
260
+ 0: select * from test;
261
+ a | b | c
262
+ ---+---+---
263
+ (0 rows)
264
+ 0: drop table test;
265
+ DROP
266
+ 0q: ... <quitting>
267
+ 1q: ... <quitting>
268
+ 2q: ... <quitting>
269
+
243
270
-- split update is to implement updating on hash keys,
244
271
-- it deletes the tuple and insert a new tuple in a
245
272
-- new segment, so it is not easy for other transaction
You can’t perform that action at this time.
0 commit comments