Download Latest Version dolt-windows-amd64.zip (40.0 MB) Google Add to Preferred Sources
Home / v2.6.0
Name Modified Size InfoDownloads / Week
Parent folder
dolt-2.6.0-1.aarch64.rpm < 20 hours ago 40.8 MB
0
dolt-2.6.0-1.x86_64.rpm < 20 hours ago 44.0 MB
0
install.sh < 20 hours ago 3.2 kB
0
dolt-windows-amd64.7z < 20 hours ago 23.3 MB
0
dolt-windows-amd64.zip < 20 hours ago 40.0 MB
0
dolt-darwin-arm64.tar.gz < 20 hours ago 41.1 MB
0
dolt-darwin-amd64.tar.gz < 20 hours ago 43.6 MB
0
dolt-linux-arm64.tar.gz < 20 hours ago 40.7 MB
0
dolt-linux-amd64.tar.gz < 20 hours ago 44.0 MB
0
2.6.0 source code.tar.gz < 20 hours ago 12.6 MB
0
2.6.0 source code.zip < 20 hours ago 14.4 MB
0
README.md < 20 hours ago 35.9 kB
0
Totals: 12 Items   344.5 MB 0

Minor Version Bump

This change introduces changes to the dolt_merge() operation which will alter the merge behavior for long running branches which have multiple merges. The previous behavior would incorrectly choose merge results without fully walking the commit graph. The new behavior more correctly matches Git's merge behavior for this rare scenarios.

Applications which automatically merge may run into conflicts in your merge which were previously not raised. The previous behavior would incorrectly choose the newest change, and it's possible an application depends on that behavior. As this behavior is not backwards compatible, we have opted to perform a minor version bump.

Merged PRs

dolt

  • 12192: dtables: mark commit_hash index non-unique in dolt_commit_ancestors Fix [#12178]
  • 12182: Warn on three-dot diffs with several merge bases; fix three-dot log This is the third and final fix for 12050, related to dolt diff FOO...BAR warning when there are multiple merge bases. Fixes: https://github.com/dolthub/dolt/issues/12050
  • 12174: go: remotesrv: Fix some warts in uploaded file handling.
  • Fix MD5 upload verification so that it happens before the table file is added to the store. We do this by verifying on the Read() path once we hit EOF or expected-size bytes.
  • Fix the upload path to never overwrite a table file that's already in the store. Dolt keeps an invariant when the table file is added to the store that it was able to be opened. Overwriting with new contents can break that invariant.
  • Verify that chunk addresses as they appear in indexes match the content-based hash of the uploaded chunks.
  • 12168: Do not warn on persisted sqlserver.cluster global config options Fix [#12127] Close [#12144]
  • 12154: Bump Go to 1.27.3 Bumps the Go SDK from 1.26.2 to 1.27.3 in go.mods, Bazel, Dockerfiles, and release/build scripts. Also brings the stale SysbenchDockerfile (1.23.3) up to date. Also adds a direct apple_support dep in proto/MODULE.bazel so macOS uses its cc toolchain. Xcode 27's clang lists SDKSettings.json in depfiles, which the rules_cc auto-configured toolchain rejects as an absolute path inclusion.
  • 12153: Unset branch upstream tracking when removing remote Fix [#11529] Close [#12151]
  • 12151: Clear branch upstreams when a remote is removed Fixes [#11529]. dolt remote remove deleted the remote but left branches.<name> entries in repo_state.json that still carried the head merge ref. The dolt_remote procedure (which the CLI goes through) first rewrote every branch tracking the remote to remote: "" and then removed the remote, so the entry survived with an empty remote. That looks like an upstream on the local repository, which Git expresses with .. Git instead drops branch.<name>.remote and .merge when the remote is removed. This removes the loop in dolt_remote.go that blanked the remote name, and clears the branch entries whose remote is the removed one in RepoState.RemoveRemote (CLI path) and SessionStateAdapter.RemoveRemote (in memory and the persisted file), through a nil-safe helper ClearBranchUpstreamsForRemote. Branches that track a different remote are kept. Testing: a Go test in env for RemoveRemote and one for a nil branch map; a bats case in remote-cmd.bats that follows the repro from the issue (push -u origin b1:other, remote remove origin, no "b1" entry left in repo_state.json). The bats case fails with the previous dolt_remote.go and passes with this change; remote-cmd.bats passes as a whole and go vet is clean. The rest of the suites were not run. This change was made with Claude Code.
  • 12149: go: Run the dolt CLI and sql-server on engine-owned variables. Part of a body of work to remove the global SystemVariables and StatusVariables registries and make them state on the Engine itself.
  • The dolt CLI and sql-server run their engines on engine-owned variable bundles instead of the global registries. Persisted globals load into the bundle from the root environment.
  • dolt sql and dolt debug restrict LOAD_FILE by setting secure_file_priv in the engine they run. dolt_log_level keeps its value in the server's engine; the logrus level it sets is still process-wide.
  • Persisted variable load errors print once. Split out of [#12134] together with the runtime consumers it builds on in [#12148].
  • 12148: sql: Bind Dolt runtime to engine variables. Part of a body of work to remove the global SystemVariables and StatusVariables registries and make them state on the Engine itself.
  • Runtime consumers read the executing engine's bundle: sessions, transactions, merge, rebase, stats, binlog, nested engines, CREATE DATABASE hooks, engine bootstrap and test harnesses.
  • Adds sqle.NewEngineVariablesForEnv, sqle.AssignSystemVariables and sqle.DoltSystemVariableNames.
  • Callers that pass no bundle keep main's behavior on the global registries. The dolt CLI and sql-server still pass none, so their behavior is unchanged here; [#12149] switches them over. doltgresql, driver and ld keep working after the auto-bump. Split out of [#12134] together with the CLI and sql-server switch-on in [#12149].
  • 12147: go/cmd/dolt/commands: Close filter-branch's per-commit database. filter-branch creates a new database for each commit it replays and never closed them, so their sequence trackers could still be reading the store when dolt closed it. That panic made filter-branch.bats fail intermittently. The rebased engine now closes the databases it owns, and filter-branch closes the engine. Adds a unit regression test.
  • 12146: Stopped quoting extended type column defaults Builds on top of:
  • https://github.com/dolthub/go-mysql-server/pull/4045
  • 12144: go/cmd/dolt: Don't warn on persisted sqlserver.cluster config options ## Summary When sql-server runs with a cluster config, it persists the cluster role and epoch to the config json under sqlserver.cluster.* (for example after CALL dolt_assume_cluster_role('standby', 1)). The CLI's config validator only allowed known options and the sqlserver.global prefix, so every later dolt command printed warnings like: Warning: Unknown global config option 'sqlserver.cluster.dolt_cluster_role'. Use `dolt config --global --unset sqlserver.cluster.dolt_cluster_role` to remove. Fixes [#12127] ## Changes
  • Add env.SqlServerClusterPrefix (sqlserver.cluster) and use it for cluster.PersistentConfigPrefix, so the two can't drift apart.
  • Add env.IsKnownConfigOption, which accepts the known options plus the sqlserver.global and sqlserver.cluster namespaces, and use it for both the local and global config warnings in cmd/dolt/dolt.go.
  • dolt config --add/--set validation is unchanged. ## Testing
  • New unit test TestIsKnownConfigOption in libraries/doltcore/env.
  • New bats test in config.bats that writes persisted cluster keys to the global config and checks that dolt version prints no warning. It fails on main and passes with this change. The full config.bats file passes.
  • Checked by hand: with a global config containing sqlserver.cluster.dolt_cluster_role, sqlserver.cluster.dolt_cluster_role_epoch and a bogus key, only the bogus key still produces a warning.
  • go test ./libraries/doltcore/env ./libraries/doltcore/sqle/cluster, go vet, gofmt.
  • 12137: dolt assist: default to gpt-5.6-terra before gpt-3.5-turbo shuts down on 2026-10-23 dolt assist falls back to gpt-3.5-turbo when --model isn't given. OpenAI shuts that model down on the API on October 23, 2026, and its deprecations page lists gpt-5.6-terra as the replacement. After that date, dolt assist stops working for OpenAI users who rely on the default. This changes openAiDefaultModel and the --model help text to gpt-5.6-terra. The request body only sends model and messages, so nothing else needs to change. --model still overrides the default, and the OrcaRouter provider isn't touched. Close [#12161]
  • 12133: sql: Bind Dolt bootstrap to engine variables. Part of a body of work to remove the global SystemVariables and StatusVariables registries and make them state on the Engine itself.
  • Engine, server and CLI bootstrap can carry an engine-owned bundle through variable definition, persisted settings and config application.
  • Includes the listener-timeout fix and isolated test-server grants.
  • 12132: sql: Add registry-aware Dolt variable bootstrap helpers. Part of a body of work to remove the global SystemVariables and StatusVariables registries and make them state on the Engine itself.
  • Add registry-aware Dolt variable definition, persistence and replication-hook helpers alongside the existing global ones.
  • 12125: Implement git's ORT merge mechanism Related: https://github.com/dolthub/dolt/issues/12050

go-mysql-server

Commits


Dependabot compatibility score Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/dolthub/go-mysql-server/network/alerts).
  • 4045: Converted extended type column defaults with assignment casts Fixes an issue integrators were running into, as they don't necessarily follow MySQL's rules.
  • 4044: Assign column IDs to "Unreferenceable" columns Fixes [#12141] "Unreferenceable" columns (columns that have internal names that don't match their aliases) were added to the outscope via addColumn instead of newColumn, which meant they were never assigned a column ID. As a result, view/subquery scopes were not being mapped to the correct columns, causing the wrong filters to be pushed down. Query plan tests changed due to more columns being added to ColSet.
  • 4041: Clear sign on negative zero during DecimalMod Fixes [#12124] This is done in DecimalDiv, but it seems like the step was skipped for DecimalMod.
  • 4039: GROUP_CONCAT: concatenate BIT values as raw bytes GROUP_CONCAT over a BIT column concatenated the decimal text of each value instead of its raw bytes, so HEX(GROUP_CONCAT(v)) returned 3335 where MySQL returns 0305. Root cause: evalExprs only keeps retType as Blob when every expression is Blob. A BIT column is BitType, so the result type became Text and groupConcatValue stringified each value through ConvertToCollatedString. BIT now takes its own raw big-endian byte form. Fixes [#11422] Test: TestGroupConcat_BitConcatsRawBytes fails before this change ("35") and passes after ("\x03\x05").
  • 4033: Build information_schema column defaults without the parser Package initialization parsed the SQL text of 237 column defaults, each twice, through a context that copies every system variable, to build the literals 0 and "". The package was the most expensive to initialize in a native program (6.6 ms, 20,000 allocations), and a program compiled to JavaScript spent over a second there before its first statement. The schemas now build those literals directly, and a test checks that they equal what the parser returns.
  • 4023: Added AggregateCallResolver for functions that share a name with an aggregate
  • 4011: Prune unselected columns from Columns() Doltgres PR: https://github.com/dolthub/doltgresql/pull/3631 There's a potential problem with the plan tree that can lead to correctness issues, and it has to do with how nodes report their ColumnSet (their list of column IDs) and their schema, and how these both interact in the presence of ProjectedTables (table nodes that contain a projection stating which columns are selected). Currently, if a table contains a projection, then Schema() will return a projected schema with the unselected columns removed, but Columns() will still report the entire column set. This is ostensibly done because we rely on having the full set of columns when computing functional dependencies and when checking if an index can be used for a lookup, although I'm not 100% certain whether this is actually necessary in practice. This descrepency can cause some problems: there are multiple places in the code where we assume that these functions will return results with the same number of elements. In some cases, we detect when there's a mismatch and fetch the Schema of the table's underlying primary key index and use that instead. There are a few cases where we failed to do this check and could panic: I've already submitted a PR that fixes one of these. The reason I've been doing all this is because of an optimization we do that may not be correct. We have an optimization that replaces trivial subqueries with the underlying table. For example: SELECT a from (SELECT a, b FROM table) becomes SELECT a from table. In the plan tree, this means transforming a SubqueryAlias into a TableAlias. Currently, the TableAlias uses the same columnIds as the underlying table, while GetFields in the top-level query will refer to the now non-existent subquery columns. This can theoretically lead to problems in subsequent passes. For example, GetFields that referred to the subqueries now have ColumnIds that no longer appear in the table, and will be resolved by name instead. This is probably safe because I don't think it's possible for the table to have multiple columns with the same name in this specific circumstance. But it does mean that any optimization pass that looks at columnIds to match GetFields to tables will no longer work here, which can inhibit future optimization. This was the problem I initially encountered: I'm rewriting the rowIter to work like a register-machine that uses the columnId as the register number. This meant that these GetFields were reading from a different register than the one being written to. But the bigger problem with the current behavior is what happens when we have a CTE that gets referenced multiple times in the same query. For example: WITH SELECT * FROM test_table AS cte SELECT cte a JOIN cte b ON ... After the optimization runs, the plan will contain two TableAlias nodes that contain the same columnIds, which isn't supposed to happen. GetFields that resolve based on the ColumnId are now ambiguous, and a subsequent analysis pass might behave incorrectly. In order to fix this, we need to ensure that every column in the query has a unique ColumnId after the subquery is inlined. There's a couple ways we could do this: ## Use the ColumnIds from the original Subquery in the generated TableAlias and the underlying ResolvedTable. This was my initial approach, but it ran into a problem with ProjectedTables. TableAlias nodes use the same ColumnIds as the underlying table, which means the entire column set even for ProjectedTables. (So, the TableAlias for SELECT x, y FROM x_y_z would have three ColumnIds, for the above-mentioned reasons.) But the subquery has a ColumnId for each column in the Subquery's schema, so the subquery would only have two ColumnIds. Because of this mismatch, we can't reuse the Subquery ColumnIds for the TableAlias. This PR attempts to make that possible by removing the requirement that tables Columns() method returns a value for unselected columns. During the pruneCols analysis pass, it rewrites tables' ColSet to remove columns that aren't actually selected. This simplifies logic in many places and generates different plans with lower costs and row-estimates. However, I have a gut feeling that this may impede functional dependency analysis in some cases and prevent us from selecting an index if we are only selecting a prefix of that index's columns. Some more testing is required. This PR also breaks Dolt because the implementations for Dolt-specific system tables like DoltLog need to be updated for this. It seems like DoltLog implements ProjectedTable but always returns the full schema in calls to DoltLog.Schema(), which is inconsistent with other table implementations. This may be a bug that should be fixed anyway, and I need to understand what's actually happening here. ## Use the ColumnIds from the original Subquery only in the generated TableAlias, and not the underlying ResolvedTable. Basically prune ColumnIds from TableAlias but not the underlying table. This allows both ColSets to exist in the plan, and analysis passes can access them both if needed. However this will likely complicate the logic of other optimizations, since it's no longer possible to treat the two node types identically. This PR doesn't attempt this solution, but it's an alternate option.
  • 4002: Preserve column metadata for parenthesized GROUP BY references Resolve parenthesized GROUP BY column references through the existing column-resolution path, preserving the metadata needed by HAVING. Adds regressions for nested/qualified references, aliases, NULLs, and constant grouping. Found while fixing the HAVING regression in GMS [#4001].
  • 3932: When replacing a subquery with a table alias, push the subquery columnIds into the underlying table. When parsing a query, Dolt assigns an ID to every column in the query. These IDs are meant to be unique. But due to an oversight, there are some queries that contain duplicate column IDs. Dolt attempts to remove trivial subqueries by inlining them into the parent query. If a common table expression expression is referenced multiple times and inlined multiple times, then each of the inlined Table nodes will have the same column Ids. If a subsequent analysis pass assumes that every table node has unique IDs, it may behave incorrectly. I don't think that this oversight actually results in incorrect behavior: we only inline trivial subqueries that don't contain any filters or projections, so there won't be any GetField expressions referencing any of the columns with duplicate IDs. However, there's another downside to this operation: By erasing the SubqueryAlias node, we erase the map that maps ColumnIds on the SubqueryAlias to the ColumnIds in the subquery. GetField expressions that referred to columns on the subquery alias will still use those Ids, and subsequent analysis passes won't be able to connect them to the columns in the new TableAlias nodes. The fix for both of these issues is to modify the set of the ColumnIds in the inlined tables to use the ColumnIds originally assigned to the removed SubqueryAlias. This both prevents the query from containing duplicate IDs while also maintaining the mapping between GetFields in the parent query and the columns they reference. This PR results in improvements to several PlanTests. One thing I still need to investigate before merging is what happens if only some of the columns are selected from the table being inlined. It looks like previously the Table node's ColSet contained a element for every column in the table, even the ones that aren't selected, but after this change, it is rewritten to only have an element for every column in the subquery alias. It's not clear what impact this has on analysis passes and needs to be understood before merging. This was fixed with https://github.com/dolthub/go-mysql-server/pull/4011

Closed Issues

  • 12178: sql-server: dolt_commit_ancestors lookup by commit_hash fails with "max1Row iterator returned more than one row" for a merge commit
  • 12050: Merge and three-dot diff use only the tallest of several merge bases, which breaks the schema-branch pattern
  • 11422: Dolt GROUP_CONCAT(BIT) concatenates numeric text instead of BIT bytes.
  • 12127: dolt sql warns on persisted sqlserver.cluster.* global config options
  • 11529: dolt remote remove leaves an upstream config behind
  • 12141: Column field indexes don't seem to be correctly assigned in views
  • 4050: INSERT() counts bytes instead of characters on multibyte strings
Source: README.md, updated 2026-10-23