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

kv: make RaftCommand.ClosedTimestamp nullable #60992

Merged

Conversation

nvanbenschoten
Copy link
Member

Fixes #60852.
Fixes #60833.
Fixes #58298.
Fixes #59428.
Fixes #60756.
Fixes #60848.
Fixes #60849.

In #60852 and related issues, we saw that the introduction of a non-nullable RaftCommand.ClosedTimestamp, coupled with the ClosedTimestampFooter encoding strategy we use, led to encoded RaftCommand protos with their ClosedTimestamp field set twice. This is ok from a correctness perspective, at least as protobuf is concerned, but it led to a subtle interaction where the process of passing through sideloading (maybeInlineSideloadedRaftCommand(maybeSideloadEntriesImpl(e))) would reduce the size of an encoded RaftCommand by 3 bytes (the encoded size of an empty hlc.Timestamp). This was resulting in an uncommittedSize leak in Raft, which was eventually stalling on its MaxUncommittedEntriesSize limit.

This commit fixes this issue by making RaftCommand.ClosedTimestamp nullable. With the field marked as nullable, it will no longer be encoded as an empty timestamp when unset, ensuring that when the encoded ClosedTimestampFooter is appended, it contains the only instance of the ClosedTimestamp field.

cc. @cockroachdb/bulk-io

@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Contributor

@andreimatei andreimatei left a comment

Choose a reason for hiding this comment

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

:LGTM:

thanks for the catch

Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @nvanbenschoten)


pkg/kv/kvserver/kvserverpb/proposer_kv.proto, line 260 at r1 (raw file):

  // This field is set through ClosedTimestampFooter hackery. Unlike in the
  // ClosedTimestampFooter, the field is nullable here so that it does not get
  // encoded when empty. This prevents the field from being encoded twice in the

want to put a similar comment on max_lease_index?

Fixes cockroachdb#60852.
Fixes cockroachdb#60833.
Fixes cockroachdb#58298.
Fixes cockroachdb#59428.
Fixes cockroachdb#60756.
Fixes cockroachdb#60848.
Fixes cockroachdb#60849.

In cockroachdb#60852 and related issues, we saw that the introduction of a non-nullable
`RaftCommand.ClosedTimestamp`, coupled with the `ClosedTimestampFooter` encoding
strategy we use, led to encoded `RaftCommand` protos with their ClosedTimestamp
field set twice. This is ok from a correctness perspective, at least as protobuf
is concerned, but it led to a subtle interaction where the process of passing
through sideloading (`maybeInlineSideloadedRaftCommand(maybeSideloadEntriesImpl(e))`)
would reduce the size of an encoded RaftCommand by 3 bytes (the encoded size of
an empty `hlc.Timestamp`). This was resulting in an `uncommittedSize` leak in
Raft, which was eventually stalling on its `MaxUncommittedEntriesSize` limit.

This commit fixes this issue by making `RaftCommand.ClosedTimestamp` nullable.
With the field marked as nullable, it will no longer be encoded as an empty
timestamp when unset, ensuring that when the encoded `ClosedTimestampFooter` is
appended, it contains the only instance of the `ClosedTimestamp` field.
@nvanbenschoten nvanbenschoten force-pushed the nvanbenschoten/closedTSFieldNullable branch from 1740033 to e833703 Compare February 23, 2021 15:49
Now that `ClosedTimestampFooter` exists, be more specific and symmetric.
@nvanbenschoten nvanbenschoten force-pushed the nvanbenschoten/closedTSFieldNullable branch from e833703 to e46511a Compare February 23, 2021 15:54
Copy link
Member Author

@nvanbenschoten nvanbenschoten left a comment

Choose a reason for hiding this comment

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

TFTR.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @andreimatei)


pkg/kv/kvserver/kvserverpb/proposer_kv.proto, line 260 at r1 (raw file):

Previously, andreimatei (Andrei Matei) wrote…

want to put a similar comment on max_lease_index?

Done.

@nvanbenschoten
Copy link
Member Author

bors r+

@craig
Copy link
Contributor

craig bot commented Feb 23, 2021

This PR was included in a batch that was canceled, it will be automatically retried

@craig
Copy link
Contributor

craig bot commented Feb 23, 2021

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
3 participants