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

storage: remove spurious call to maybeInlineSideloadedRaftCommand #31627

Merged
merged 2 commits into from
Oct 22, 2018

Conversation

tbg
Copy link
Member

@tbg tbg commented Oct 19, 2018

Entries are "thinned" only when passed to r.append() (i.e. written to
disk) and they are always returned "fat" from Entries() (i.e. Raft's way
to get entries from disk). Consequently Raft never sees thin entries and
won't ask us to commit them.

Touches #31618.

Release note: None

@tbg tbg requested a review from a team October 19, 2018 11:26
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@tbg
Copy link
Member Author

tbg commented Oct 19, 2018

This would be really awkward to get wrong, so @bdarnell and @nvanbenschoten to double check please.

Copy link
Member

@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.

:lgtm: happy to see the boundary between thin and inlined entries further clarified. I should have addressed this in #20573. It might be worth adding a similar assertion to the one in that PR.

This brings up an interesting quetion - what happens to the raftEntryCache when we have sideloaded entries? Looks like we keep the entries inlined in the cache. That seems like a quick way to completely flush the rest of the cache, which is size-bound. I can't imagine that's good for any other Ranges that happen to live on the same Store as a Range in the middle of an AddSstRequest proposal.

Reviewed 1 of 1 files at r1, 1 of 1 files at r2.
Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (and 1 stale)

@tbg
Copy link
Member Author

tbg commented Oct 22, 2018

Filed an issue for the entry cache: #31688 (hope GitHub didn't lose it)

bors r=nvanbenschoten,benesch

@tbg
Copy link
Member Author

tbg commented Oct 22, 2018

bors r=nvanbenschoten,benesch

tbg added 2 commits October 22, 2018 16:13
Entries are "thinned" only when passed to `r.append()` (i.e. written
to disk) and they are always returned "fat" from `Entries()` (i.e.
Raft's way to get entries from disk). Consequently Raft never sees
thin entries and won't ask us to commit them.

Touches cockroachdb#31618.

Release note: None
If this were passed as nil, we'd be returning "thin" (i.e. with
sideloading payloads not inlined) Entries. This isn't supposed
to happen, but check it.

See:
cockroachdb#31618 (comment).

Release note: None
@tbg tbg force-pushed the fix/useless-inline branch from e5df97a to 5500cb5 Compare October 22, 2018 14:13
@craig
Copy link
Contributor

craig bot commented Oct 22, 2018

Canceled

@tbg
Copy link
Member Author

tbg commented Oct 22, 2018

bors r=nvanbenschoten,benesch

craig bot pushed a commit that referenced this pull request Oct 22, 2018
31556: importccl: re-enable job control tests r=mjibson a=mjibson

I tracked down the problem. It was that after the CANCEL JOB was issued,
sometimes the 2nd stage of the IMPORT (the shuffle) would have started,
and sometimes it wouldn't have. If it did not start then RunJob would
block forever trying to send on the allowResponse chan. Fix this by
making a draining go routine after the first block.

Closes #24623
Closes #24658

Release note: None

31627: storage: remove spurious call to maybeInlineSideloadedRaftCommand r=nvanbenschoten,benesch a=tschottdorf

Entries are "thinned" only when passed to `r.append()` (i.e. written to
disk) and they are always returned "fat" from `Entries()` (i.e. Raft's way
to get entries from disk). Consequently Raft never sees thin entries and
won't ask us to commit them.

Touches #31618.

Release note: None

31695: bitarray: don't allow FromEncodingParts to return invalid bit array r=knz a=benesch

It is invalid for a bit array's lastBitsUsed field to be greater than
64. The FromEncodingParts function, however, would happily construct
an invalid bitarray if given a too-large lastBitsUsed value. Teach the
FromEncodingParts to return an error instead.

This presented as a panic when attempting to pretty-print a key with a
bitarray whose lastBitsUsed encoded value was 65. Such a key can be
created when calling PrefixEnd on a key with a bitarray whose
lastBitsUsed value is 64. By returning an error instead, the
pretty-printing code will try again after calling UndoPrefixEnd and be
able to print the key.

Fix #31115.

Release note: None

31697: partitionccl: deflake TestDropIndexWithZoneConfigCCL r=danhhz,eriktrinh a=benesch

A particularly adversarial goroutine schedule can cause this test to
observe the moment in time where the data is dropped but the zone config
is not. Deflake by retrying the check for the dropped zone config until
it succeeds (or times out).

Fix #31678.

Release note: None

Co-authored-by: Matt Jibson <[email protected]>
Co-authored-by: Tobias Schottdorf <[email protected]>
Co-authored-by: Nikhil Benesch <[email protected]>
@craig
Copy link
Contributor

craig bot commented Oct 22, 2018

Build succeeded

  • GitHub CI (Cockroach)

@craig craig bot merged commit 5500cb5 into cockroachdb:master Oct 22, 2018
@tbg tbg deleted the fix/useless-inline branch November 23, 2018 11:49
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.

4 participants