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

[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	1786.28/s	1781.07/s	-0.3%
groupby_scan_postgres	135.24/s	134.65/s	-0.5%
index_join_postgres	643.45/s	639.87/s	-0.6%
index_join_scan_postgres	787.65/s	784.22/s	-0.5%
index_scan_postgres	24.44/s	23.69/s	-3.1%
oltp_delete_insert_postgres	777.49/s	790.56/s	+1.6%
oltp_insert	668.87/s	657.58/s	-1.7%
oltp_point_select	2820.92/s	2788.47/s	-1.2%
oltp_read_only	2861.93/s	2845.49/s	-0.6%
oltp_read_write	2295.49/s	2298.08/s	+0.1%
oltp_update_index	711.74/s	696.01/s	-2.3%
oltp_update_non_index	740.32/s	720.87/s	-2.7%
oltp_write_only	1740.90/s	1637.56/s	-6.0%
select_random_points	1821.98/s	1810.78/s	-0.7%
select_random_ranges	1067.58/s	1063.77/s	-0.4%
table_scan_postgres	23.29/s	22.34/s	-4.1%
types_delete_insert_postgres	763.76/s	745.21/s	-2.5%
types_table_scan_postgres	10.15/s	9.76/s	-3.9%

[itoqa]

Commit: 7b0d73b: 5 test cases ran, 4 passed ✅, 1 additional finding ⚠️.

Summary

This run covers core database behavior in both normal and edge conditions, including cross-context data resolution, schema object lifecycle and conflict handling, and startup behavior under invalid configuration. Overall product behavior remains stable for the change under review, with one known reliability gap observed outside the scope of this PR.

Safe to merge — there are no regressions, new failures, or previously flagged failures attributable to this PR. The only failing area is a pre-existing high-severity replication degraded-mode issue that remains a follow-up reliability concern but is not a merge blocker for this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Resolution	Explicit references to dbb.public.items from a dba session correctly read and wrote only dbB data, while default and schema-only lookups remained scoped to dbA.
✅	—	Root	Procedure create, replace, and drop operations each produced the expected dirty-state transitions and persisted distinct commit roots, then returned to a clean working tree after commit.
✅	—	Root	Merging diverged branches with different procedure bodies correctly reports a conflict and preserves the unresolved state instead of silently selecting one side.
✅	—	Startup	Using invalid TLS certificate and key paths correctly caused doltgres to exit with code 1 and print a clear TLS configuration error before serving SQL traffic.
⚠️		Startup	Replication initialization is treated as fire-and-forget: connectivity errors are retried in the background and then the worker exits after max failures, while server startup has already succeeded and continues serving SQL.

Additional Findings Details

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

🟠 Replication startup enters silent degraded mode

• Severity: High
• Description: Replication initialization is treated as fire-and-forget: connectivity errors are retried in the background and then the worker exits after max failures, while server startup has already succeeded and continues serving SQL.
• Impact: Instances configured for replication can run without actually replicating data after startup, leaving users with stale or missing replicas. This can break failover readiness and recovery expectations until the replication process is manually restored.
• Steps to Reproduce:
  1. Start doltgres with postgres_replication fields populated, but point postgres_port to an unreachable upstream service (for example 127.0.0.1:5433 with no listener).
  2. Observe startup logs: server reports ready and accepts SQL connections on port 5432 while replication retries in the background.
  3. After repeated connection failures, observe the replicator shuts down and SQL traffic still succeeds, leaving replication inactive without startup failure.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: In server/server.go, startReplication validates only non-empty replication fields and then launches replicator.StartReplication in a goroutine before returning success to startup. In server/logrepl/replication.go, handleErrWithRetry logs and retries errors until maxConsecutiveFailures is reached, then StartReplication returns and shuts down the replicator. Because startup does not await or gate on initial replication health, misconfigured or unreachable upstream replication endpoints can produce a silent degraded state. A targeted fix is to perform an initial synchronous replication connectivity/bootstrap check before reporting server readiness (or fail startup when replication is configured but cannot establish), while preserving background retry behavior for post-start transient failures.

Evidence Package

• text/STARTUP-2/STARTUP-2-replication-silent-degraded-evidence.txt — 4 KB

Tip

Reply with @itoqa to send us feedback on this test run.

[github-actions]

	Main	PR
Total	42090	42090
Successful	18275	18275
Failures	23815	23815
Partial Successes1	5335	5335

	Main	PR
Successful	43.4189%	43.4189%
Failures	56.5811%	56.5811%

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩