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

jobs: ensure that async index dropping is needed #40439

Merged
merged 1 commit into from
Sep 10, 2019

Conversation

pbardea
Copy link
Contributor

@pbardea pbardea commented Sep 3, 2019

We drop indexes through an async schema changer which eventually gets removes an
index with ClearRange. When this happens the index drop job is not marked as
completed, but instead marked as waiting for GC. However, if we DROP the table
that the index references in the same transaction, then we mark the index drop
job as done and we don't want to override this.

This PR ensures and tests that we don't override already successful index dropping
jobs that would be created as explained above.

Addresses #39260.

Release note: None

@cockroach-teamcity
Copy link
Member

This change is Reviewable

@pbardea pbardea changed the title jobs: ensure that async index dropping is needed [wip] jobs: ensure that async index dropping is needed Sep 3, 2019
@pbardea pbardea force-pushed the txn-drop-index branch 12 times, most recently from f017a50 to 5b71525 Compare September 5, 2019 16:30
@pbardea pbardea changed the title [wip] jobs: ensure that async index dropping is needed jobs: ensure that async index dropping is needed Sep 5, 2019
@pbardea pbardea force-pushed the txn-drop-index branch 2 times, most recently from 5fd645b to 72d0f1c Compare September 5, 2019 18:54
Copy link
Contributor

@thoszhang thoszhang 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 @lucy-zhang and @pbardea)


pkg/jobs/jobs.go, line 150 at r1 (raw file):

// CheckSuccessStatus verifies the status of the job and returns an error if the job's
// status isn't Succeeded.
func (j *Job) CheckSuccessStatus(ctx context.Context) error {

This method is kind of unintuitive. I see that it's supposed to be like CheckRunning(), but CheckRunning() is supposed to be used to basically assert that the job is running and return an error otherwise (as far as I can tell), whereas CheckSuccessStatus() can be expected to return either result. Would returning a boolean instead make more sense?


pkg/sql/schema_changer.go, line 1324 at r1 (raw file):

			// was on was dropped in the same txn, we mark the index drop job
			// as successful.
			jobSucceeded = true

Is it also possible for the job to be failed?


pkg/sql/logictest/testdata/logic_test/schema_change_in_txn, line 1693 at r1 (raw file):

DROP TABLE t, t2

I think we usually just leave a single empty line between subtests.


pkg/sql/logictest/testdata/logic_test/schema_change_in_txn, line 1725 at r1 (raw file):

COMMIT;

Same here.

Copy link
Contributor Author

@pbardea pbardea 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 @lucy-zhang)


pkg/jobs/jobs.go, line 150 at r1 (raw file):

Previously, lucy-zhang (Lucy Zhang) wrote…

This method is kind of unintuitive. I see that it's supposed to be like CheckRunning(), but CheckRunning() is supposed to be used to basically assert that the job is running and return an error otherwise (as far as I can tell), whereas CheckSuccessStatus() can be expected to return either result. Would returning a boolean instead make more sense?

Done. I agree that it's a good idea to make this method return a bool (and updated it to do so). The underlying call to j.Update still returns an error which still feels a bit awkward to me, but it seems to be the standard interface for reading jobs metadata info (see https://github.com/cockroachdb/cockroach/blob/master/pkg/jobs/update.go#L78 for more info).


pkg/sql/schema_changer.go, line 1324 at r1 (raw file):

Previously, lucy-zhang (Lucy Zhang) wrote…

Is it also possible for the job to be failed?

I wasn't able to find a case where we currently would call done() on a job that is already failed. However, giving it more thought I don't think it makes sense to update the status of a job that is already in a terminal state, especially since this is intended to be a logging function. I updated the CheckSuccessfulStatus to CheckTerminalStatus which checks to see if the jobs is in any terminal state (i.e. in a state where the state should no longer change).


pkg/sql/logictest/testdata/logic_test/schema_change_in_txn, line 1693 at r1 (raw file):

Previously, lucy-zhang (Lucy Zhang) wrote…

I think we usually just leave a single empty line between subtests.

Done.


pkg/sql/logictest/testdata/logic_test/schema_change_in_txn, line 1725 at r1 (raw file):

Previously, lucy-zhang (Lucy Zhang) wrote…

Same here.

Done.

@pbardea
Copy link
Contributor Author

pbardea commented Sep 9, 2019

RFAL

Copy link
Contributor

@thoszhang thoszhang 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 @lucy-zhang and @pbardea)


pkg/sql/logictest/testdata/logic_test/schema_change_in_txn, line 1725 at r1 (raw file):

Previously, pbardea (Paul Bardea) wrote…

Done.

I forgot one thing. Could you add a brief comment explaining what this is testing?

We drop indexes through an async schema changer which eventually gets
removes an index with `ClearRange`. When this happens the index drop job
is not marked as completed, but instead marked as waiting for GC.
However, if we DROP the table that the index references in the same
transaction, then we mark the index drop job as done and we don't want
to override this.

This PR ensures and tests that we don't override already successful
index dropping jobs that would be created as explained above.

Release note: None
Copy link
Contributor Author

@pbardea pbardea 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 @lucy-zhang)


pkg/sql/logictest/testdata/logic_test/schema_change_in_txn, line 1725 at r1 (raw file):

Previously, lucy-zhang (Lucy Zhang) wrote…

I forgot one thing. Could you add a brief comment explaining what this is testing?

Done.

@pbardea
Copy link
Contributor Author

pbardea commented Sep 10, 2019

bors r+

craig bot pushed a commit that referenced this pull request Sep 10, 2019
40439: jobs: ensure that async index dropping is needed r=pbardea a=pbardea

We drop indexes through an async schema changer which eventually gets removes an
index with `ClearRange`. When this happens the index drop job is not marked as
completed, but instead marked as waiting for GC. However, if we DROP the table
that the index references in the same transaction, then we mark the index drop
job as done and we don't want to override this.

This PR ensures and tests that we don't override already successful index dropping
jobs that would be created as explained above.

Addresses #39260.

Release note: None

Co-authored-by: Paul Bardea <pbardea@gmail.com>
@craig
Copy link
Contributor

craig bot commented Sep 10, 2019

Build succeeded

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