[auto-bump] [no-release-notes] dependency by coffeegoddd

[coffeegoddd]

☕ An Automated Dependency Version Bump PR 👑

Initial Changes

The changes contained in this PR were produced by `go get`ing the dependency.

```bash
go get github.com/dolthub/[dependency]/go@[commit]
```

[github-actions]

	Main	PR
covering_index_scan_postgres	1290.62/s	${\color{red}DNF}$
index_join_postgres	186.78/s	${\color{red}DNF}$
index_join_scan_postgres	202.98/s	${\color{red}DNF}$
index_scan_postgres	12.02/s	${\color{red}DNF}$
oltp_point_select	2320.38/s	${\color{red}DNF}$
oltp_read_only	1833.46/s	${\color{red}DNF}$
select_random_points	130.12/s	${\color{red}DNF}$
select_random_ranges	1014.89/s	${\color{red}DNF}$
table_scan_postgres	11.76/s	${\color{red}DNF}$
types_table_scan_postgres	5.43/s	${\color{red}DNF}$

[itoqa]

Ito Test Report ❌

12 test cases ran. 1 failed, 4 additional findings, 7 passed.

Across 12 test cases, 7 passed and 5 failed, with high-severity defects concentrated in startup and metadata concurrency: a PR-introduced compile-time API mismatch in server/tables/dtables/ignore.go blocks server launch and ReadyForQuery, startup safety/readiness checks miss critical failure modes (configured data-dir guard order, fragile first-run default DB bootstrap DSN, and replication errors not gating readiness), and concurrent renames from the same source can both succeed. At the same time, protocol and metadata behavior was otherwise solid in this run, including correct bind type inference and same-session bind recovery, proper handling/recovery of injected default-database creation failure, expected rename-collision rejection, legacy collation normalization fallback, and coherent rollback/transactional rename semantics.

❌ Failed (1)

Category	Summary	Screenshot
Protocol	⚠️ Confirmed compile-time API mismatch prevents server startup, so StartupMessage handshake cannot reach ReadyForQuery.

⚠️ Startup handshake blocked by compile regression

• What failed: The server build fails before process startup, so the connection never reaches authentication completion and ReadyForQuery; expected behavior is successful startup and handshake progression.
• Impact: Core protocol workflows are unavailable because the server cannot start. Any pgwire test or user connection depending on startup readiness fails until the compile mismatch is fixed.
• Steps to reproduce:
  1. Build and start the server using the current dependency set from go.mod.
  2. Observe the build error from server/tables/dtables/ignore.go where GetStringAdaptiveValue is called with an outdated argument list.
  3. Attempt a StartupMessage connection to localhost:5432 and confirm ReadyForQuery is never reached because startup did not complete.
• Stub / mock context: SCRAM authentication was temporarily bypassed for local protocol testing, but the observed failure happens earlier at compile time: server/tables/dtables/ignore.go uses an outdated GetStringAdaptiveValue call signature after dependency upgrades.
• Code analysis: I inspected server/tables/dtables/ignore.go, server/connection_handler.go, and dependency bump changes in go.mod. getIgnoreTablePatternKey still calls GetStringAdaptiveValue with an outdated argument list, which aligns with the build failure evidence; startup handshake logic itself appears intact but is unreachable because compilation fails first.
• Why this is likely a bug: The production source has a deterministic compile-time signature mismatch in a tracked Go file, which prevents server startup and therefore blocks the primary protocol handshake path.

Relevant code:

server/tables/dtables/ignore.go (lines 61-66)

// getIgnoreTablePatternKey reads the pattern key from a tuple and returns it.
func getIgnoreTablePatternKey(ctx context.Context, keyDesc *val.TupleDesc, keyTuple val.Tuple) (string, error) {
	key, ok, err := keyDesc.GetStringAdaptiveValue(0, nil, keyTuple)
	if err != nil {
		return "", err
	}

server/connection_handler.go (lines 221-233)

case *pgproto3.StartupMessage:
	if err = h.handleAuthentication(sm); err != nil {
		return false, err
	}
	if err = h.sendClientStartupMessages(); err != nil {
		return false, err
	}
	if err = h.chooseInitialParameters(sm); err != nil {
		return false, err
	}
	return true, h.send(&pgproto3.ReadyForQuery{
		TxStatus: byte(ReadyForQueryTransactionIndicator_Idle),
	})

go.mod (lines 9-15)

github.com/dolthub/dolt/go v0.40.5-0.20260505201141-aefca7f01a23
github.com/dolthub/eventsapi_schema v0.0.0-20260310172945-37a9265ade69
github.com/dolthub/flatbuffers/v23 v23.3.3-dh.2
github.com/dolthub/go-mysql-server v0.20.1-0.20260505171600-5a9dda3f04ff
github.com/dolthub/pg_query_go/v6 v6.0.0-20251215122834-fb20be4254d1
github.com/dolthub/sqllogictest/go v0.0.0-20240618184124-ca47f9354216
github.com/dolthub/vitess v0.0.0-20260505163811-77e5224be390

✅ Passed (7)

Category	Summary	Screenshot
Engine	Parse/Bind fallback correctly infers bind variable types when ParameterOIDs are omitted or zero.
Engine	Injected default-database creation failure was surfaced, and restart without injection recovered cleanly.
Engine	First bind failed as expected, then corrected bind on the same prepared statement succeeded (42) without reconnect.
Metadata	ALTER TABLE employees RENAME TO teams returned a table-exists error and both original tables remained accessible, matching expected collision behavior.	N/A
Metadata	Previous BLOCKED status was due to missing fixture, not product logic. Source confirms normalization is implemented: when serialized collation is invalid, default collation is returned, matching expected compatibility behavior.	N/A
Metadata	Injected failure produced clean operation failure without partial rename divergence, and retry behavior remained deterministic, satisfying expected atomic/coherent behavior under fault.	N/A
Metadata	Dependent DDL and DML in the same transaction resolved against the new table identity consistently, with commit producing coherent catalog objects and data.	N/A

ℹ️ Additional Findings (4)

These findings are unrelated to the current changes but were observed during testing.

Category	Summary	Screenshot
Engine	⚠️ Startup does not reject an existing configured data directory because the guard runs before the data-dir reload.
Engine	⚠️ First-run default database bootstrap can fail because the bootstrap connection does not target a guaranteed-existing database.
Engine	⚠️ Replication startup errors do not gate readiness; server remains queryable after unreachable downstream failure.
Metadata	⚠️ Confirmed real application bug. Concurrent rename operations can both succeed because rename validation/editing occurs against each session root without a guard that forces one operation to fail, matching the previously observed both-success outcome.

⚠️ Startup guard misses configured data directory

• What failed: Startup should abort when the configured target data directory already contains a Dolt/Doltgres repository, but the server continues startup because the early guard checks the initial cwd-bound environment instead of the configured data directory.
• Impact: A core startup safety check is bypassed for configured data directories, so invalid startup states are accepted. Users can unintentionally boot against an existing database directory when startup should fail fast.
• Steps to reproduce:
  1. Set DOLTGRES_DATA_DIR to a path that already contains an initialized Dolt/Doltgres repository.
  2. Launch Doltgres from a different current working directory.
  3. Observe that startup proceeds instead of aborting for the existing configured data directory.
• Stub / mock context: SCRAM authentication was intentionally bypassed so startup behavior could be tested without auth gating, and startup ran with local harness-driven process control instead of full production auth flow. A local compatibility patch in server/tables/dtables/ignore.go and a generated auth.db fixture were also present during execution.
• Code analysis: I reviewed server/server.go and found the HasDoltDataDir check is executed before dEnv is reloaded to ssCfg.DataDir(), so the guard evaluates the wrong filesystem context.
• Why this is likely a bug: The guard that should validate the configured data directory runs before switching to that directory, so it can miss the exact invalid condition the test targets.

Relevant code:

server/server.go (lines 93-97)

if dEnv.HasDoltDataDir() {
    cwd, _ := dEnv.FS.Abs(".")
    return nil, errors.Errorf("Cannot start a server within a directory containing a Dolt or Doltgres database. "+
        "To use the current directory (%s) as a database, start the server from the parent directory.", cwd)
}

server/server.go (lines 132-139)

// Reload the dolt environment with the correct data dir that was specified in the configuration.
// This initial dEnv instance is loaded for the current working directory.
dataDirFs, err := dEnv.FS.WithWorkingDir(ssCfg.DataDir())
if err != nil {
    return nil, err
}
dEnv = env.Load(ctx, dEnv.GetUserHomeDir, dataDirFs, doltdb.LocalDirDoltDB, dEnv.Version)

⚠️ First run bootstrap database connection is fragile

• What failed: The first-run bootstrap path can fail while creating the default database because the internal bootstrap connection string omits a guaranteed-existing database context.
• Impact: New instances can fail during initial database bootstrap, breaking first-run startup for a core workflow. This can leave users unable to bring up a fresh server without manual intervention.
• Steps to reproduce:
  1. Create a fresh empty data directory and set DOLTGRES_DB to postgres.
  2. Start the server and let it enter first-run initialization.
  3. Observe bootstrap failure while creating the default database.
• Stub / mock context: SCRAM authentication was intentionally bypassed so startup initialization could be exercised without authentication-handshake failures masking bootstrap behavior. A local compatibility patch in server/tables/dtables/ignore.go and a generated auth.db fixture were also present to stabilize the run environment.
• Code analysis: In server/server.go, first-run logic calls createDefaultDatabase after startup. That function builds a DSN without a database name and then executes CREATE DATABASE for the default DB, which can fail when no suitable initial database context exists.
• Why this is likely a bug: The bootstrap connection omits an explicit known-existing database, making first-run database creation fragile in the exact path meant to initialize a fresh environment.

Relevant code:

server/server.go (lines 181-185)

if initializeDefaultDatabase {
    err = createDefaultDatabase(ssCfg)
    if err != nil {
        return nil, err
    }
}

server/server.go (lines 199-214)

func createDefaultDatabase(cfg doltservercfg.ServerConfig) error {
    user, password := auth.GetSuperUserAndPassword()
    dbName := getDefaultDatabaseName(user)

    dsn := fmt.Sprintf("postgres://%s:%s@localhost:%d", user, password, cfg.Port())

    // Connect to the server and create the default database with the given name.
    ctx := context.Background()
    conn, err := pgx.Connect(ctx, dsn)
    if err != nil {
        return err
    }
    defer conn.Close(ctx)

    _, err = conn.Exec(ctx, fmt.Sprintf("CREATE DATABASE %s;", dbName))
    return err
}

⚠️ Startup readiness ignores replication failure

• What failed: The server is expected to fail startup (or become unavailable) when replication cannot establish a downstream connection, but it continues accepting SQL traffic in a half-ready state.
• Impact: Operators can see a "started" server that is silently running without healthy replication, which risks inconsistent behavior and delayed incident detection. There is no practical workaround for users who rely on startup readiness to guarantee replication health.
• Steps to reproduce:
  1. Configure replication with valid syntax but an unreachable downstream host and port.
  2. Start the server and wait for the normal startup-ready signal.
  3. Run a SQL query after replication connection errors occur and observe that queries still succeed.
• Stub / mock context: Local SCRAM authentication was bypassed for deterministic access, and replication was intentionally pointed to an unreachable local endpoint to validate readiness behavior under real connection failure.
• Code analysis: I inspected server/server.go and server/logrepl/replication.go; startup launches replication in a background goroutine without awaiting its result, while replication connection/runtime errors are returned only inside the goroutine and never propagated to the startup success path.
• Why this is likely a bug: Replication failures are real runtime errors in production code, but the startup flow detaches and ignores them, allowing readiness to report success when a required subsystem has already failed.

Relevant code:

server/server.go (lines 188-192)

// TODO: shutdown replication cleanly when we stop the server
_, err = startReplication(cfg, ssCfg)
if err != nil {
    return nil, err
}

server/server.go (lines 267-269)

cli.Println("Starting replication")
go replicator.StartReplication(*cfg.PostgresReplicationConfig.SlotName)
return replicator, nil

server/logrepl/replication.go (lines 186-189)

replicationConn, err := pgx.Connect(context.Background(), r.replicationDns)
if err != nil {
    return err
}

server/logrepl/replication.go (lines 377-383)

if err != nil {
    if errors.Is(err, errShutdownRequested) {
        return nil
    }
    log.Println("Error during replication:", err)
    return err
}

⚠️ Concurrent table rename race allows dual success

• What failed: Both rename commands can return success, producing both destination names from one original source when exactly one rename should win and the other should fail.
• Impact: Concurrent schema changes can produce invalid catalog outcomes and break assumptions that rename is conflict-safe. Teams running parallel migrations may end up with contradictory table state without a reliable failure signal.
• Steps to reproduce:
  1. Open two SQL sessions against the same database.
  2. Run ALTER TABLE t_old RENAME TO t_a in one session and ALTER TABLE t_old RENAME TO t_b in the other at nearly the same time.
  3. Check resulting table names after both statements complete.
  4. Observe both destination tables exist even though only one rename should succeed.
• Stub / mock context: Real SCRAM password verification was bypassed to keep local sessions deterministic, then the concurrent rename workflow was executed against the same metadata path used in production code. No table-rename result was stubbed or mocked.
• Code analysis: I inspected rename orchestration in core/rootvalue.go and table-map mutation logic in core/storage/storage.go. RenameTable delegates directly to EditTablesMap, and EditTablesMap performs local existence checks plus delete/update without any compare-and-swap or cross-session conflict guard that would force one concurrent rename to fail.
• Why this is likely a bug: The rename flow applies check-then-mutate logic on session-local state without a synchronization guard, so concurrent operations can both pass preconditions and commit incompatible outcomes.

Relevant code:

core/rootvalue.go (lines 791-815)

func (root *RootValue) RenameTable(ctx context.Context, oldName, newName doltdb.TableName) (doltdb.RootValue, error) {
	_, rawOldID, objID, err := rootobject.ResolveName(ctx, root, oldName)
	if err != nil {
		return nil, err
	}
	if objID == objinterface.RootObjectID_None {
		newStorage, err := root.st.EditTablesMap(ctx, root.vrw, root.ns, []storage.TableEdit{{OldName: oldName, Name: newName}})
		if err != nil {
			return nil, err
		}
		newRoot := root.withStorage(newStorage)
		// ... sequence-owner updates ...
		return collection.UpdateRoot(ctx, newRoot)
	}
}

core/storage/storage.go (lines 195-215)

if e.OldName.Name != "" {
	oldaddr, err := am.Get(ctx, encodeTableNameForAddressMap(e.OldName))
	// ...
	if oldaddr.IsEmpty() {
		return RootStorage{}, doltdb.ErrTableNotFound
	}
	if !newaddr.IsEmpty() {
		return RootStorage{}, doltdb.ErrTableExists
	}
	err = ae.Delete(ctx, encodeTableNameForAddressMap(e.OldName))
	if err != nil {
		return RootStorage{}, err
	}
	err = ae.Update(ctx, encodeTableNameForAddressMap(e.Name), oldaddr)
	if err != nil {
		return RootStorage{}, err
	}
}

Commit: 63a7154

View Full Run

---

Tell us how we did: Give Ito Feedback