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

ttl: do not remove all table TTL settings on RESET (ttl_expire_after) #110252

Merged
merged 3 commits into from
Sep 15, 2023
Merged

ttl: do not remove all table TTL settings on RESET (ttl_expire_after) #110252

merged 3 commits into from
Sep 15, 2023

Conversation

ecwall
Copy link
Contributor

@ecwall ecwall commented Sep 8, 2023

Fixes #109138

Previously running RESET (ttl_expire_after) would remove all table TTL
settings if ttl_expiration_expression was set.

This PR fixes the schema changer to only remove all TTL settings on
RESET (ttl).

Release note (bug fix): RESET (ttl_expire_after) no longer incorrectly
removes ttl_expiration_expression.

@ecwall ecwall requested a review from a team September 8, 2023 14:28
@ecwall ecwall requested review from a team as code owners September 8, 2023 14:28
@ecwall ecwall requested a review from a team September 8, 2023 14:28
@ecwall ecwall requested review from a team as code owners September 8, 2023 14:28
@ecwall ecwall requested a review from a team September 8, 2023 14:28
@ecwall ecwall requested a review from a team as a code owner September 8, 2023 14:28
@ecwall ecwall requested review from abarganier, rachitgsrivastava, DarrylWong, rhu713, sumeerbhola, miretskiy and michae2 and removed request for a team September 8, 2023 14:28
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@ecwall ecwall removed the request for review from a team September 8, 2023 14:29
pkg/sql/alter_table.go Show resolved Hide resolved
pkg/sql/schema_changer.go Show resolved Hide resolved
pkg/sql/schema_changer.go Show resolved Hide resolved
descriptorChanged = true
}
if !descriptorChanged {
// Add TTL mutation so that job is scheduled in SchemaChanger.
Copy link
Contributor

Choose a reason for hiding this comment

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

super nit: "enqueue TTL mutation ..." might be better since the direction might be add or drop.

case before != nil && after == nil:
direction = descpb.DescriptorMutation_DROP
default:
descriptorChanged = true
Copy link
Contributor

Choose a reason for hiding this comment

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

while you are on this, let's improve around descriptorChanged in the following two ways:

  1. Rename it to something like canDirectlyModifyDescriptor so we know that it's true if we are not enqueuing any mutations and can directly modify the descriptor here;
  2. Return value from this function will be something like canDirectlyModifyDescriptor || hasEnqueuedAnyMutation

Copy link
Contributor

@Xiang-Gu Xiang-Gu left a comment

Choose a reason for hiding this comment

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

Good work! I have two last questions:

  1. If both ttl_expire_after and ttl_expirataion_expression are set, and we reset ttl_expire_after, the new code path, as I understand it, will be
    1). Enqueue a DropColumn mutation (so we drop "expire_at" column)
    2). Don't enqueue a TTL mutation but instead directly modify the TTL field on the descriptor
    Correct?

  2. If we only have ttl_expire_after set, and we reset it, it seems to me the same two things above will happen, but maybe later in descriptor validation, we will reject it, right?

@ecwall
Copy link
Contributor Author

ecwall commented Sep 14, 2023

Good work! I have two last questions:

  1. If both ttl_expire_after and ttl_expirataion_expression are set, and we reset ttl_expire_after, the new code path, as I understand it, will be
    1). Enqueue a DropColumn mutation (so we drop "expire_at" column)
    2). Don't enqueue a TTL mutation but instead directly modify the TTL field on the descriptor
    Correct?
  2. If we only have ttl_expire_after set, and we reset it, it seems to me the same two things above will happen, but maybe later in descriptor validation, we will reject it, right?

1-1) It drops crdb_internal_expiration not expire_at.
1-2) It will not directly modify the descriptor because the mutation will modify the descriptor.
2) You can't reset ttl_expire_after if ttl_expiration_expression is not set - this did not change and there is a subtest for it.

@ecwall ecwall requested a review from Xiang-Gu September 14, 2023 18:24
@Xiang-Gu
Copy link
Contributor

It drops crdb_internal_expiration not expire_at.

Oh, my previous thoughts were wrong. Thanks!

It will not directly modify the descriptor because the mutation will modify the descriptor.

This is somewhat surprising. Are you sure? In this case, before != nil && after != nil so no TTL mutations will be enqueued and the descriptor is modified right away. Or did I miss something?

This question and two of my unresolved comments are the only things I have. Thanks for doing this!

Copy link
Collaborator

@rafiss rafiss left a comment

Choose a reason for hiding this comment

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

lgtm, apart from Xiang's comments

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @chrisseto, @ecwall, and @Xiang-Gu)

@ecwall
Copy link
Contributor Author

ecwall commented Sep 14, 2023

It will not directly modify the descriptor because the mutation will modify the descriptor.

This is somewhat surprising. Are you sure? In this case, before != nil && after != nil so no TTL mutations will be enqueued and the descriptor is modified right away. Or did I miss something?

This code is confusing because it may also be modified in the before != nil && after != nil block, but after that it will either add a mutation or change the descriptor immediately. I did not change this behavior.

Copy link
Contributor Author

@ecwall ecwall 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 @chrisseto and @Xiang-Gu)


pkg/sql/alter_table.go line 1958 at r6 (raw file):

Previously, Xiang-Gu (Xiang Gu) wrote…

while you are on this, let's improve around descriptorChanged in the following two ways:

  1. Rename it to something like canDirectlyModifyDescriptor so we know that it's true if we are not enqueuing any mutations and can directly modify the descriptor here;
  2. Return value from this function will be something like canDirectlyModifyDescriptor || hasEnqueuedAnyMutation

I took this name from descriptorChanged at the call site. If you want to change this, can you file a separate issue?

The call site documents that descriptorChanged should be true only if no mutations are added so it should be changed there also.

// Commands can either change the descriptor directly (for  
// alterations that don't require a backfill) or add a mutation to  
// the list.  
descriptorChanged := false

pkg/sql/alter_table.go line 1961 at r6 (raw file):

Previously, Xiang-Gu (Xiang Gu) wrote…

super nit: "enqueue TTL mutation ..." might be better since the direction might be add or drop.

I took this from the function name I am calling (AddModifyRowLevelTTLMutation) the function calling handleTTLStorageParamChange also refers to it as "add a mutation" so can you file a separate issue to rename it everwhere?

scheduleID and createStmt indexes used to populate slice literals for show
results.

Rename these to avoid accidental usage and to prevent shadowing in the sql
package.

Release note: None
Copy link
Contributor

@Xiang-Gu Xiang-Gu 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 @chrisseto and @ecwall)


pkg/sql/alter_table.go line 1958 at r6 (raw file):

Previously, ecwall (Evan Wall) wrote…

I took this name from descriptorChanged at the call site. If you want to change this, can you file a separate issue?

The call site documents that descriptorChanged should be true only if no mutations are added so it should be changed there also.

// Commands can either change the descriptor directly (for  
// alterations that don't require a backfill) or add a mutation to  
// the list.  
descriptorChanged := false

I think descriptorChanged means is there any updates made to the descriptor. We further make updates into two categories:
1). enqueue a mutation to the descriptor's mutation slice
2). modify other fields directly in the descriptor

In handleTTLStorageParamChange, descriptorChanged is not correctly set according to this standard. For example, it's set to false when we enqueue a mutation. That's why I suggested we should rename the variable (within handleTTLStorageParamChange) to something like canDirectlyModifyDescriptor. And that's also why the return value of handleTTLStorageParamChange should be something like canDirectlyModifyDescriptor || hasEnqueuedAnyMutation. Nothing outside handleTTLStorageParamChange should change.

Split large subtests into smaller subtests to make debugging easier.

Release note: None
Fixes #109138

Previously running `RESET (ttl_expire_after)` would remove all table TTL
settings if `ttl_expiration_expression` was set.

This PR fixes the schema changer to only remove all TTL settings on
`RESET (ttl)`.

Release note (bug fix): `RESET (ttl_expire_after)` no longer incorrectly
removes `ttl_expiration_expression`.
Copy link
Contributor Author

@ecwall ecwall 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 @chrisseto and @Xiang-Gu)


pkg/sql/alter_table.go line 1958 at r6 (raw file):

Previously, Xiang-Gu (Xiang Gu) wrote…

I think descriptorChanged means is there any updates made to the descriptor. We further make updates into two categories:
1). enqueue a mutation to the descriptor's mutation slice
2). modify other fields directly in the descriptor

In handleTTLStorageParamChange, descriptorChanged is not correctly set according to this standard. For example, it's set to false when we enqueue a mutation. That's why I suggested we should rename the variable (within handleTTLStorageParamChange) to something like canDirectlyModifyDescriptor. And that's also why the return value of handleTTLStorageParamChange should be something like canDirectlyModifyDescriptor || hasEnqueuedAnyMutation. Nothing outside handleTTLStorageParamChange should change.

Please make another ticket to address this with example(s) of where it is being set to true when a mutation is added. Based on the usage of descriptorChanged, it only needs to be set if no mutations are added:

if !addedMutations && !descriptorChanged {

@ecwall ecwall requested a review from Xiang-Gu September 15, 2023 15:50
Copy link
Contributor

@Xiang-Gu Xiang-Gu left a comment

Choose a reason for hiding this comment

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

I will take a look at the examples. LGTM! Good work!

@Xiang-Gu
Copy link
Contributor

@ecwall here you go #110727

@ecwall
Copy link
Contributor Author

ecwall commented Sep 15, 2023

bors r=Xiang-Gu

@ecwall
Copy link
Contributor Author

ecwall commented Sep 15, 2023

@ecwall here you go #110727

Great, thanks.

@craig
Copy link
Contributor

craig bot commented Sep 15, 2023

Build succeeded:

@craig craig bot merged commit 55731bd into cockroachdb:master Sep 15, 2023
@blathers-crl
Copy link

blathers-crl bot commented Sep 15, 2023

Encountered an error creating backports. Some common things that can go wrong:

  1. The backport branch might have already existed.
  2. There was a merge conflict.
  3. The backport branch contained merge commits.

You might need to create your backport manually using the backport tool.


error creating merge commit from 3e7bb4b to blathers/backport-release-22.1-110252: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 22.1.x failed. See errors above.


error creating merge commit from 5fba729 to blathers/backport-release-23.1-110252: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 23.1.x failed. See errors above.


error creating merge commit from 5fba729 to blathers/backport-release-23.1.11-rc-110252: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 23.1.11-rc failed. See errors above.


🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-23.1.x Flags PRs that need to be backported to 23.1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ttl: ttl_expire_after and ttl_expiration_expression should not be allowed to be set at the same time
5 participants