sql: rework SHOW REGIONS to SHOW REGIONS FROM CLUSTER #56627
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This change is |
otan
force-pushed
the
show_regions_from_cluster
branch
from
20d80bf to
49f6872
Compare
otan
force-pushed
the
show_regions_from_cluster
branch
from
49f6872 to
5b19543
Compare
ajstorm
requested changes
Nov 13, 2020
There was a problem hiding this comment.
Reviewed 7 of 8 files at r1.
Reviewable status:complete! 0 of 0 LGTMs obtained (waiting on @ajstorm and @otan)
pkg/sql/parser/sql.y, line 5127 at r1 (raw file):
// %Category: DDL // %Text: // SHOW REGIONS CLUSTER
Should this be FROM CLUSTER?
pkg/sql/parser/sql.y, line 5128 at r1 (raw file):
// %Text: // SHOW REGIONS CLUSTER // SHOW REGIONS FOR DATABASE <database>
Should this be FROM DATABASE
otan
force-pushed
the
show_regions_from_cluster
branch
from
5b19543 to
191cb9c
Compare
otan
commented
Nov 13, 2020
There was a problem hiding this comment.
Reviewable status:
pkg/sql/parser/sql.y, line 5127 at r1 (raw file):
Previously, ajstorm wrote…
Should this be
FROMCLUSTER?
Done.
pkg/sql/parser/sql.y, line 5128 at r1 (raw file):
Previously, ajstorm wrote…
Should this be
FROMDATABASE
Done.
ajstorm
approved these changes
Nov 13, 2020
There was a problem hiding this comment.
LGTM
Reviewable status:
Release note (sql change): SHOW REGIONS functionality is now deferred to SHOW REGIONS FROM CLUSTER.
otan
force-pushed
the
show_regions_from_cluster
branch
from
191cb9c to
8e58c1e
Compare
|
bors r=ajstorm tftr! |
|
Build failed: |
|
bors r=ajstorm |
craig bot
pushed a commit
that referenced
this pull request
Nov 13, 2020
56373: hlc: introduce synthetic flag on timestamps r=nvanbenschoten a=nvanbenschoten Informs #52745. Informs #36431. This commit introduces an 8-bit `flags` field on the hlc timestamp struct. The flags are used to provide details about the timestamp and its meaning. They do not affect the sort order of Timestamps. The commit then introduces the first flag: SYNTHETIC. As discussed in #52745, a synthetic timestamp is defined as a timestamp that makes no claim about the value of clocks in the system. While standard timestamps are pulled from HLC clocks and indicate that some node in the system has a clock with a reading equal to or above its value, a synthetic timestamp makes no such indication. By avoiding a connection to "real time", synthetic timestamps can be used to write values at a future time and to indicate that observed timestamps do not apply to such writes for the purposes of tracking causality between the write and its observers. Observed timestamps will be a critical part of implementing non-blocking transactions (#52745) and fixing the interaction between observed timestamps and transaction refreshing (#36431). The original plan was to reserve the high-order bit in the logical portion of a timestamp as a "synthetic bit". This is how I began implementing things, but was turned off for a few reasons. First, it was fairly subtle and seemed too easy to get wrong. Using a separate field is more explicit and avoids a class of bugs. Second, I began to have serious concerns about how the synthetic bit would impact timestamp ordering. Every timestamp comparison would need to mask out the bit or risk being incorrect. This was even true of the LSM custom comparator. This seemed difficult to get right and seemed particularly concerning since we're planning on marking only some of a transaction's committed values as synthetic to fix #36431, so if we weren't careful, we could get atomicity violations. There were also minor backwards compatibility concerns. But a separate field is more expensive in theory, so we need to be careful. However, it turns out that a separate field is mostly free in each case that we care about. In memory, the separate field is effectively free because the Timestamp struct was previously 12 bytes but was always padded out to 16 bytes when included as a field in any other struct. This means that the flags field is replacing existing padding. Over the wire, the field will not be included when zero and will use a varint encoding when not zero, so again, it is mostly free. In the engine key encoding, the field is also not included when zero, and takes up only 1 byte when non-zero, so it is mostly free. ---- First three commits from #56477. @sumeerbhola I'm hoping you can take a look at the engine-level changes in the `introduce synthetic flag on timestamps` commit (4th commit as of the time of writing). I think the key encoding added here makes sense, but want to make sure you're on board. One possible concern is that we introduce a new 13-byte suffix, which means that combined with a 4-byte sequence number (see #41720 (comment)), we'd collide with the 17 byte `engineKeyVersionLockTableLen`. @tbg do you mind being the primary reviewer here? I think you know the most about the motivations for this change and will have a good sense of whether this is the best way to introduce additional state on timestamps. 56437: cli, ui: dismiss release notes signup banner per environment variable r=knz,dhartunian a=nkodali Previously, the signup banner could only be dismissed manually. For internal testing purposes, this banner is unnecessary. This change provides a way to dismiss the signup banner upon start of a cluster via the cli by setting the environment variable COCKROACH_UI_RELEASE_NOTES_SIGNUP_DISMISSED=true. Resolves #46998 Release note: none 56627: sql: rework SHOW REGIONS to SHOW REGIONS FROM CLUSTER r=ajstorm a=otan Resolves #56331 Release note (sql change): SHOW REGIONS functionality is now deferred to SHOW REGIONS FROM CLUSTER. Co-authored-by: Nathan VanBenschoten <[email protected]> Co-authored-by: Namrata Kodali <[email protected]> Co-authored-by: Oliver Tan <[email protected]>
|
Build failed (retrying...): |
|
Build failed (retrying...): |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #56331
Release note (sql change): SHOW REGIONS functionality is now deferred to
SHOW REGIONS FROM CLUSTER.