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 work in #1186 adds an API for modifying a network interface, including setting a new primary interface. The implementation there uses a transaction, since setting a primary involves modifying two rows (old / new primary) in slightly different ways.
It is possible to implement this in a single query, using two common table expressions that update each of these rows accordingly. However, doing that in the current version of CRDB yields the following error:
ERROR: multiple modification subqueries of the same table "network_interface" are not supported unless they all use INSERT without ON CONFLICT; this is to prevent data corruption, see documentation of sql.multiple_modifications_of_table.enabled
That's related to this bug, where multiple statements modifying the same row in a query cause data corruption. Now our query would modify two different rows, so we could reasonably expect that the bug itself wouldn't matter. However, even running the query relies on a cluster setting that we'd need to set.
This issue tracks updating the internals of this query, which we should wait to do until that CRDB bug is resolved. The basic outlines of the query can be found in this comment.
The text was updated successfully, but these errors were encountered:
The work in #1186 adds an API for modifying a network interface, including setting a new primary interface. The implementation there uses a transaction, since setting a primary involves modifying two rows (old / new primary) in slightly different ways.
It is possible to implement this in a single query, using two common table expressions that update each of these rows accordingly. However, doing that in the current version of CRDB yields the following error:
That's related to this bug, where multiple statements modifying the same row in a query cause data corruption. Now our query would modify two different rows, so we could reasonably expect that the bug itself wouldn't matter. However, even running the query relies on a cluster setting that we'd need to set.
This issue tracks updating the internals of this query, which we should wait to do until that CRDB bug is resolved. The basic outlines of the query can be found in this comment.
The text was updated successfully, but these errors were encountered: