You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The expected behavior of UPSERT (and possibly other mutation statements) is that its rows affected count should reflect the number of rows actually modified. However, CockroachDB gets this wrong:
INSERT INTO kv VALUES(1,2);
INSERT INTO kv VALUES (1,2), (3,4) ON CONFLICT(k) DO NOTHING; -- returns 2 rows affected, even though just 1 row was upserted
This in turn means that the GRANT statement will bump the role membership table version on every invocation, even if nothing is changed (= excessive chattiness).
(So this is not a correctness bug)
The text was updated successfully, but these errors were encountered:
knz
added
the
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
label
Apr 19, 2018
23373: sql: fix the batching behavior of mutation statements, especially with RETURNING r=knz a=knz
Fixes#22304.
Fixes#23156.
Fixes#24928.
To review:
- @RaduBerinde for the physical property propagation. Check the order_by test, confirm that this is enables optimizations of DELETE in a WITH clause or [ ... ]
- @jordanlewis for overall design of the new `batchedPlanNode` interface.
- @andreimatei@jordanlewis for correctness of the batching behavior (like we discussed - I think this does everything you want)
Co-authored-by: Raphael 'kena' Poss <knz@cockroachlabs.com>
Found while working on a test for the rows affected value on statements that have no result rows.
Hinted by a chat with @mberhault.
The expected behavior of UPSERT (and possibly other mutation statements) is that its rows affected count should reflect the number of rows actually modified. However, CockroachDB gets this wrong:
This in turn means that the GRANT statement will bump the role membership table version on every invocation, even if nothing is changed (= excessive chattiness).
(So this is not a correctness bug)
The text was updated successfully, but these errors were encountered: