server,settingswatcher: adopt settingswatcher in system tenant #70566
Labels
C-enhancement
Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
T-server-and-security
DB Server & Security
Comments
ajwerner
added
the
C-enhancement
This was referenced Sep 22, 2021
ajwerner
added a commit
to ajwerner/cockroach
that referenced
this issue
Oct 25, 2021
This is intended as a short-term workaround to improve performance in situations of repeated schema changes, like ORM tests. We have a plan to disable the system config trigger altogether in 22.1 with This PR provides a cluster setting which allows schema change transactions to bypass triggerring an update to the system config span. These updates currently drive only the propagation of zone configs to KV and cluster settings. The cluster setting behavior is retained until we address cockroachdb#70566. Release note: None
ajwerner
added a commit
to ajwerner/cockroach
that referenced
this issue
Dec 22, 2021
This is intended as a short-term workaround to improve performance in situations of repeated schema changes, like ORM tests. We have a plan to disable the system config trigger altogether in 22.1 with This PR provides a cluster setting which allows schema change transactions to bypass triggerring an update to the system config span. These updates currently drive only the propagation of zone configs to KV and cluster settings. The cluster setting behavior is retained until we address cockroachdb#70566. Release note: None
craig bot
pushed a commit
that referenced
this issue
Dec 23, 2021
71910: sql: add a cluster setting to avoid system config triggers r=ajwerner a=ajwerner This is intended as a short-term workaround to improve performance in situations of repeated schema changes, like ORM tests. We have a plan to disable the system config trigger altogether in 22.1 with #70560. This PR provides a cluster setting which allows schema change transactions to bypass triggerring an update to the system config span. These updates currently drive only the propagation of zone configs to KV and cluster settings. The cluster setting behavior is retained until we address #70566. We have a history of these sorts of unsafe settings in `kv.raft_log.disable_synchronization_unsafe`. Release note: None Co-authored-by: Andrew Werner <[email protected]>
craig bot
pushed a commit
that referenced
this issue
Jan 3, 2022
71910: sql: add a cluster setting to avoid system config triggers r=ajwerner a=ajwerner This is intended as a short-term workaround to improve performance in situations of repeated schema changes, like ORM tests. We have a plan to disable the system config trigger altogether in 22.1 with #70560. This PR provides a cluster setting which allows schema change transactions to bypass triggerring an update to the system config span. These updates currently drive only the propagation of zone configs to KV and cluster settings. The cluster setting behavior is retained until we address #70566. We have a history of these sorts of unsafe settings in `kv.raft_log.disable_synchronization_unsafe`. Release note: None 74188: sql: fix InternalExecutor bug r=ajwerner a=ajwerner Any time we use WithSyntheticDescriptors, it has to be on an unshared internal executor. The move in #71246 to not have an internal executor hanging around for the current session hurts here. Fixes #73788 Release note: None Co-authored-by: Andrew Werner <[email protected]>
gustasva
pushed a commit
to gustasva/cockroach
that referenced
this issue
Jan 4, 2022
This is intended as a short-term workaround to improve performance in situations of repeated schema changes, like ORM tests. We have a plan to disable the system config trigger altogether in 22.1 with This PR provides a cluster setting which allows schema change transactions to bypass triggerring an update to the system config span. These updates currently drive only the propagation of zone configs to KV and cluster settings. The cluster setting behavior is retained until we address cockroachdb#70566. Release note: None
|
Closed by #70560. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
For secondary tenants, we use a rangefeed-backed mechanism to initialize and watch cluster settings. On the system tenant we use the older gossiped system config. This is unfortunate because we want to stop gossiping the system config (#70560).
Describe the solution you'd like
We should adopt the same code for the system tenant that we use for the secondary tenants.
Additional context
There's the beginnings of a WIP for this in #69269.
Epic CRDB-10489
The text was updated successfully, but these errors were encountered: