Re: Incorrect command tag row count for MERGE with a cross-partition update
От | Alvaro Herrera |
---|---|
Тема | Re: Incorrect command tag row count for MERGE with a cross-partition update |
Дата | |
Msg-id | 20230221093411.uaiwhld6t2ksl7kw@alvherre.pgsql обсуждение исходный текст |
Ответ на | Incorrect command tag row count for MERGE with a cross-partition update (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: Incorrect command tag row count for MERGE with a cross-partition update
|
Список | pgsql-hackers |
On 2023-Feb-20, Dean Rasheed wrote: > Playing around with MERGE some more, I noticed that the command tag > row count is wrong if it does a cross-partition update: > > CREATE TABLE target (a int, b int) PARTITION BY LIST (b); > CREATE TABLE target_p1 PARTITION OF target FOR VALUES IN (1); > CREATE TABLE target_p2 PARTITION OF target FOR VALUES IN (2); > INSERT INTO target VALUES (1,1); > > MERGE INTO target t USING (VALUES (1)) v(a) ON t.a = v.a > WHEN MATCHED THEN UPDATE SET b = 2; > > which returns "MERGE 2" when only 1 row was updated, because > ExecUpdateAct() will update estate->es_processed for a cross-partition > update (but not for a normal update), and then ExecMergeMatched() will > update it again. Hah. > I think the best fix is to have ExecMergeMatched() pass canSetTag = > false to ExecUpdateAct(), so that ExecMergeMatched() takes > responsibility for updating estate->es_processed in all cases. Sounds sensible. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Las mujeres son como hondas: mientras más resistencia tienen, más lejos puedes llegar con ellas" (Jonas Nightingale, Leap of Faith)
В списке pgsql-hackers по дате отправления: