dolt 1.53.1 #222921
Merged
dolt 1.53.1 #222921
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stefanb
approved these changes
May 8, 2025
|
🤖 An automated task has requested bottles to be published to this PR. Please do not push to this PR branch before the bottle commits have been pushed, as this results in a state that is difficult to recover from. If you need to resolve a merge conflict, please use a merge commit. Do not force-push to this PR branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Created by
brew bumpCreated with
brew bump-formula-pr.release notes
When a pull or push failed with an error in a HasMany call or on the initiating read of a set of chunks from the ChunkFetcher, the initiating goroutine used to close the PullChunkTracker. However, the writes to the PullChunkTracker are issued on the thread which reads and processes the chunks themselves. This meant that it was possible for the PullChunkTracker to be Closed while that thread was still issuing writes against it.
Making the chunk-reading thread responsible for the Close is more correct.
This fixes #9190.
Add pre-finalize blocking on the worker thread shutdown to dolt_gc safepoint controllers.
Add blocking on the worker thread shutdown to dolt_stats_stop(), so that a caller knows that stats have actually stopped by the time it returns.
Fix issue #6979
We define
noValidRepositoryto ensure the command has a valid target, but in that definition we callmrEnv.GetEnv()on the wrong string, so it's always null with the --branch flag. We should call it just on the name of the database, excluding the branch.A string with the database and branch is also needed later, so we need to save both variables.
We need to rebase a remote in order to see its latest changes.
Fixes #9164.
Optimize code using a more modern writing style.
go-mysql-server
(This PR changes the types in one of the tables used in tests. This improves the test coverage for
TEXTcolumns, especially when they're used in conjunction with other tables withVARCHARcolumns. None of the existing tests were testing the original type: this should be strictly increasing our test coverage.)The following plans involve computing a hash of rows to store in an in-memory hash set:
We weren't previously unwrapping wrapped values before computing hashes. The default hash implementation used the struct's
%vrepresentation to compute the hash, which has two problems:%vrepresentation of a wrapper struct is not the same as the hash of the value that the wrapper is semantically equivalent to.%vrepresentation of a wrapper struct depends on internal state, such as whether the wrapped has already been unwrapped once before (and cached the unwrapped value in an internal buffer)The simplest fix is to unwrap values before computing a row hash in the
HashOffunction.However, this fix comes at a cost: it now requires the engine to unwrap all values if they get used in any of the above plans. This will hurt performance for any of the above plans if they don't actually need to unwrap the value. For example, an UpdateJoinIter on a table with a
TEXTcolumn will now load that column from disk, even if its value is never used.A better fix might be to use the
Hash()function that is already defined on thesql.Wrapperinterface. For all existing Wrapper implementations, this returns the Dolt content address of the value, and is the same regardless of whether or not that address has previously been resolved. However, this would still return a different hash than an equivalent string. If we wanted them to return the same hash, Dolt would need to define a custom hash for strings that computes the Dolt content address of the string if it were to be stored as a Dolt chunk. This would likely be slower than Go's builtin hash for strings, although the performance might be comparable? This would likely result in worse performance for plans that don't useTEXTcolumns.Fixes: Problem modifying a column to change from float to bigint dolthub/dolt#9178
Test to be added to dolt engine tests
When altering the possible values of an enum column, the mapping between enum strings and their indexes may change. In order to alter the column correctly, we need to map the old indexes onto the new ones.
This PR fixes two bugs in that mapping process:
INSERT IGNOREstatement where the provided value for the enum is out of range. Dolt also allows setting the column to 0 directly, although MySQL does not. Previously, we were not able to alter enum columns if they contained a 0 value, but now we can.Closed Issues
Performance
| Overall Mean Multiple | 1.56 |
|-----------------------|------|