[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	1939.99/s	${\color{red}DNF}$
groupby_scan_postgres	131.35/s	${\color{red}DNF}$
index_join_postgres	685.23/s	${\color{red}DNF}$
index_join_scan_postgres	860.17/s	${\color{red}DNF}$
index_scan_postgres	24.64/s	${\color{red}DNF}$
oltp_delete_insert_postgres	856.76/s	${\color{red}DNF}$
oltp_insert	742.96/s	${\color{red}DNF}$
oltp_point_select	3067.58/s	${\color{red}DNF}$
oltp_read_only	3069.97/s	${\color{red}DNF}$
oltp_read_write	2354.40/s	${\color{red}DNF}$
oltp_update_index	762.29/s	${\color{red}DNF}$
oltp_update_non_index	810.53/s	${\color{red}DNF}$
oltp_write_only	1820.75/s	${\color{red}DNF}$
select_random_points	1952.29/s	${\color{red}DNF}$
select_random_ranges	1144.28/s	${\color{red}DNF}$
table_scan_postgres	23.51/s	${\color{red}DNF}$
types_delete_insert_postgres	815.52/s	${\color{red}DNF}$
types_table_scan_postgres	10.41/s	${\color{red}DNF}$

[itoqa]

Ito Test Report ❌

7 test cases ran. 1 failed, 1 additional finding, 5 passed.

Overall, the unified run had 7 test cases with 5 passing and 2 failing, confirming that authentication/SCRAM handshake behavior, first-run default postgres database bootstrap, and core replication start/retry-threshold scenarios generally worked as expected. The most important findings were two High-severity defects: a PR-introduced compile-time regression in server/tables/init.go (undefined sqle.HandleSchema) that blocks server build and planner/wire-flow validation, and an existing startup bug where replication authentication failures are returned by the replicator but ignored because startup launches replication asynchronously, allowing the server to appear healthy while replication is broken.

❌ Failed (1)

Category	Summary	Screenshot
Planner	⚠️ Build fails on undefined sqle.HandleSchema, preventing Parse/Bind/Execute verification.

⚠️ Server build fails after dependency API change

• What failed: The code fails to compile with undefined: sqle.HandleSchema in server/tables/init.go; expected behavior is a successful build so prepared statement Parse/Bind/Execute paths can run.
• Impact: Core server build/startup is blocked, so SQL workflows cannot run in this revision. This prevents validating and using planner/wire flows in affected environments.
• Steps to reproduce:
  1. Build or run focused tests against the current branch after the dependency bump.
  2. Compile packages that include server/tables.
  3. Observe compile failure on undefined: sqle.HandleSchema before planner flow execution.
• Stub / mock context: Temporary local setup edits were present during this run, including a flag path that can skip domain-cast constraint injection while bringing up the environment. The confirmed failure is independent of those stubs because compilation stops earlier on an undefined production symbol in server initialization code.
• Code analysis: I inspected the planner/wire flow (server/connection_handler.go, server/connection_data.go) and the failing initialization path. Planner code still includes bind-type inference for omitted/zero OIDs, but execution never reaches that logic because compilation stops at server/tables/init.go due to the missing sqle.HandleSchema API while the PR updates dependency versions in go.mod.
• Why this is likely a bug: A direct compile-time undefined symbol in production source is a concrete code defect, not a runtime test setup artifact.

Relevant code:

server/tables/init.go (lines 25-33)

// Init handles initialization of all Postgres-specific and Doltgres-specific tables.
func Init() {
	sqle.HandleSchema = func(ctx *sql.Context, schemaName string, db sqle.Database) (sql.DatabaseSchema, error) {
		if _, ok := handlers[schemaName]; ok {
			return Database{db}, nil
		}
		return db, nil
	}
	doltdb.IsValidIdentifier = core.IsValidPostgresIdentifier
}

go.mod (lines 9-13)

github.com/dolthub/dolt/go v0.40.5-0.20260601234716-990a03cd38d9
	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.20260601185611-f066a7510ce0
	github.com/dolthub/pg_query_go/v6 v6.0.0-20251215122834-fb20be4254d1

✅ Passed (5)

Category	Summary	Screenshot
Bootstrap	Server started with fresh empty data directory and default bootstrap credentials; first connection to postgres/password succeeded and current_database() returned postgres, confirming default database provisioning.
Handshake	Authentication remained enforced; invalid credentials were rejected and valid credentials succeeded.
Handshake	Valid postgres/password SCRAM startup completed and SELECT 1 succeeded.
Replication	Replication worker starts successfully with complete configuration and healthy keepalive behavior.
Replication	Retry policy enforces terminal stop at the configured threshold, with no infinite retries after endpoint restoration.

ℹ️ Additional Findings (1)

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

Category	Summary	Screenshot
Replication	⚠️ Server startup succeeds even when replication bootstrap fails at runtime with invalid replication credentials.

⚠️ Startup continues despite replication auth failure

• What failed: The server reports replication authentication failures, but startup still completes and serves SQL connections. Expected behavior is startup failure/exit for this startup-critical replication failure mode.
• Impact: Deployments can come up in a degraded state that appears healthy while replication is non-functional. Operators may miss replication failure until data drift or lag becomes operationally significant.
• Steps to reproduce:
  1. Configure replication with valid required fields but an invalid replication password.
  2. Start the server and wait for startup readiness.
  3. Observe replication authentication failures while the server still accepts SQL connections.
• Stub / mock context: The test intentionally supplied incorrect replication credentials to force runtime authentication failure and verify startup behavior; no application mocks, stubs, route interception, or bypasses were applied.
• Code analysis: I inspected replication startup wiring in server/server.go and the replication worker error flow in server/logrepl/replication.go. Startup launches replication with go replicator.StartReplication(...) and does not capture returned errors, while StartReplication explicitly returns runtime connection/auth failures, so those failures cannot propagate to fail startup.
• Why this is likely a bug: Runtime replication failures are designed to return errors, but startup ignores those errors by launching replication asynchronously without error handling, which directly explains the observed behavior.

Relevant code:

server/server.go (lines 262-269)

replicator, err := logrepl.NewLogicalReplicator(walFilePath, primaryDns, replicationDns)
if err != nil {
    return nil, err
}

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

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

func (r *LogicalReplicator) StartReplication(slotName string) error {
    standbyMessageTimeout := 10 * time.Second
    nextStandbyMessageDeadline := time.Now().Add(standbyMessageTimeout)

    lastWrittenLsn, err := r.readWALPosition()
    if err != nil {
        return err
    }

    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
}

Commit: 519faaa

View Full Run

---

Tell us how we did: Give Ito Feedback