Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

base: ensure that a SQL instance ID is not set to conflicting value #72608

Merged
merged 2 commits into from
Nov 11, 2021

Conversation

knz
Copy link
Contributor

@knz knz commented Nov 10, 2021

Informs #58938.
First commit from #72607.

Prior to this patch, a SQL instance ID container could be
assigned successively different values. This would make it possible
for erroneous code to mistakenly initialize the instance ID twice,
without any evidence that something was amiss.

This patch fixes this by using the same prevention logic that we
already use for node IDs.

@knz knz requested review from RaduBerinde, rimadeodhar and a team November 10, 2021 13:10
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Collaborator

@rimadeodhar rimadeodhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 3 of 3 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @knz and @RaduBerinde)


-- commits, line 21 at r2:

Quoted 5 lines of code…
  Prior to this patch, a SQL instance ID container could be
  assigned successively different values. This would make it possible
  for erroneous code to mistakenly initialize the instance ID twice,
  without any evidence that something was amiss.

Interesting! What sequence of events can cause this to happen and how did we detect this?


pkg/base/node_id.go, line 223 at r2 (raw file):

	}

	c.sqlInstanceID = sqlInstanceID

Nit: We can delete this, right? Seems like we are already setting c.sqlInstanceID at
oldVal := atomic.SwapInt32((*int32)(&c.sqlInstanceID), int32(sqlInstanceID)).

Prior to this patch, the SQL instance ID was not reported in log
messages, which made it hard to distinguish log messages coming from
different in-memory SQL instance servers (e.g. in tests).

This patch fixes it.

The patch also changes the log tag for SQL instances from just `sql`
to `sqli`, which is easier to search for and recognize.

Release note: None
Copy link
Contributor Author

@knz knz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @knz, @RaduBerinde, and @rimadeodhar)


-- commits, line 21 at r2:

What sequence of events can cause this

A bug in the code.

how did we detect this?

When it happened for node IDs, we detected it by being confused about why the same log file would report different node IDs in different log messages. Then we added the assertion and saw a bunch of unit tests fail.

Copy link
Contributor Author

@knz knz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @RaduBerinde and @rimadeodhar)


pkg/base/node_id.go, line 223 at r2 (raw file):

Previously, rimadeodhar (Rima Deodhar) wrote…

Nit: We can delete this, right? Seems like we are already setting c.sqlInstanceID at
oldVal := atomic.SwapInt32((*int32)(&c.sqlInstanceID), int32(sqlInstanceID)).

Oops yes you're right. fixed.

Prior to this patch, a SQL instance ID container could be
assigned successively different values. This would make it possible
for erroneous code to mistakenly initialize the instance ID twice,
without any evidence that something was amiss.

This patch fixes this by using the same prevention logic that we
already use for node IDs.

Release note: None
@knz knz force-pushed the 20211110-instance-unique branch from c5a4716 to 5196152 Compare November 11, 2021 11:37
@knz
Copy link
Contributor Author

knz commented Nov 11, 2021

TFYR!

bors r=rimadeodhar

@craig
Copy link
Contributor

craig bot commented Nov 11, 2021

Build succeeded:

@craig craig bot merged commit d7e3ceb into cockroachdb:master Nov 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants