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 bump
Created with
brew bump-formula-pr
.release notes
dolt sql
to always log in as theroot
superuserFrom the command line, when a sql-server is not running,
dolt sql
implicitly uses theroot
account to log, but if theroot
account exists with a password,dolt sql
will fail to log in. Since the user has access to the host and the database data directory, we should allowdolt sql
to log into the SQL shell, even if theroot
user has a password set. This change also makes this behavior match when a sql-server is running, and we allow superuser login through the__dolt_local_user__
account (which only exists while a sql-server is running).Expose in CLI and test too.
See: Can't delete remote branch refs that no longer exist in origin dolthub/dolt#8734
Previously a panic was very likely if any update to dolt_workspace_* involved a schema change. This change restricts the updates to the workspace tables only in cases where the schemas have not changed.
root
superuser on SQL server startupPreviously, Dolt would only create a
root
superuser on sql-server startup when no other user accounts had been created. This resulted in a behavior where users would rundolt sql-server
, create user accounts, then the next time they restart the sql-server, theroot
account would no longer be present. This behavior has surprised several customers (see Dolt's disappearingroot
user is confusing dolthub/dolt#5759) and is different from MySQL's behavior, which creates a persistentroot
superuser as part of initialization.This change modifies this behavior so that a
root
superuser is created, and persisted, the first time a SQL server is started for a database, unless the--skip-root-user-initialization
flag is specified, or if an ephemeral super user is requested with the--user
option. Subsequent runs ofdolt sql-server
do not automatically create theroot
superuser – only the first timedolt sql-server
is started when there is no privileges database yet, will trigger theroot
user to be created and the privileges database to be initializedInternally, this is implemented by detecting the presence of any user account and privilege data stored to disk (by default, in the
.doltcfg/privileges.db
file). When no user account and privilege data exists, theroot
superuser initialization logic will run. This means theprivileges.db
data is now always created on the first run ofdolt sql-server
, even if the data is empty.As part of this change, the
root
superuser is now scoped tolocalhost
, instead of%
(i.e. any host). This improves the default security posture of a Dolt sql-server and better aligns with MySQL's behavior. Customers who rely on using theroot
account to connect from non-localhost hosts, will need to either log in and alter theroot
account to allow connections from the hosts they need, or they can specify theDOLT_ROOT_HOST
and/orDOLT_ROOT_PASSWORD
environment variables to override the default host (localhost) and password ("") for theroot
account when it is initialized the first time a sql-server is launched.One side effect of this change is that
dolt sql -u <user>
may work differently for some uses. Previously, if there was no user account and privilege data persisted to disk yet (i.e. the.doltcfg/privileges.db
file), then users could specify any username and password todolt sql
(e.g.dolt sql -u doesnotexist
) and they would still be logged in – user authentication was ignored since no user account and privilege data existed. Now that the user account and privilege data is always initialized when runningdolt sql-server
, customers may no longer usedolt sql --user <user>
to log in with unknown user accounts. The workaround for this is to simply rundolt sql
without the--user
option, and Dolt will use the default local account.Fixes: Dolt's disappearing
root
user is confusing dolthub/dolt#5759Depends on: Persist and load superusers dolthub/go-mysql-server#2797
Related to: Implementing new methods from
servercfg.DoltgresConfig
dolthub/doltgresql#1113Documentation updates: Adjust Docker docs with info on
DOLT_ROOT_HOST
andDOLT_ROOT_PASSWORD
dolthub/docs#2460go-mysql-server
Full join should exhaust right side, not return as soon as we EOF the left iterator.
fixes: [Bug]
FULL OUTER JOIN
not commutative, and not giving correct results dolthub/dolt#8735This is a bit unintuitive, but hoisting projections above sorts in the binder seems to uniformly improve projection pruning because we will always combine it with the top-level return projection.
fixes: Sort/Alias dependency conflict preventing prune dolthub/dolt#8736
fixes: [Bug] Incorrect SUM calculation in CTE with correlated subquery dolthub/dolt#8724
Distinct CTE references need unique column and table ids.
Once we spool a batch of rows to client, there's no reason to keep them in memory.
Fixes mydumper OOMs in deterministic fashion for large database dolthub/dolt#8718
Previously, superusers were persisted to disk, but never loaded back again when the database was restarted. This essentially made all superusers ephemeral, since they only lasted for the duration of a SQL server process.
This change loads persisted superusers from disk, and also adds a new function to create ephemeral superusers that do not get persisted to disk.
This also includes a fix for the event scheduler to use a privileged account so that it can load events from all databases.
vitess
ALTER TABLE
statementsparses more partition options as no-ops
fixes: Parser support for adding/removing partition dolthub/dolt#8744
starting by
andterminated by
orderthe
starting by
andterminated by
clauses inload data
statements can appear in any order and any number of times.Closed Issues
root
user is confusing