[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	1803.04/s	1800.39/s	-0.2%
groupby_scan_postgres	135.76/s	131.30/s	-3.3%
index_join_postgres	644.96/s	638.67/s	-1.0%
index_join_scan_postgres	795.52/s	789.05/s	-0.9%
index_scan_postgres	24.91/s	24.44/s	-1.9%
oltp_delete_insert_postgres	770.94/s	770.71/s	-0.1%
oltp_insert	660.35/s	662.57/s	+0.3%
oltp_point_select	2822.83/s	2871.72/s	+1.7%
oltp_read_only	2881.07/s	2887.87/s	+0.2%
oltp_read_write	2257.26/s	2281.89/s	+1.0%
oltp_update_index	695.21/s	703.56/s	+1.2%
oltp_update_non_index	702.63/s	730.51/s	+3.9%
oltp_write_only	1631.62/s	1716.86/s	+5.2%
select_random_points	1834.60/s	1848.51/s	+0.7%
select_random_ranges	1071.38/s	1087.21/s	+1.4%
table_scan_postgres	23.32/s	23.07/s	-1.1%
types_delete_insert_postgres	721.25/s	752.07/s	+4.2%
types_table_scan_postgres	8.17/s	8.08/s	-1.2%

[itoqa]

Commit: 5b99d62: 5 test cases ran, 0 failed ❌, 4 passed ✅, 1 additional finding ⚠️.

Summary

Coverage focused on core database behavior across normal operation and resilience scenarios, including initial startup defaults, relation lookup consistency, and robust handling of invalid query inputs without destabilizing sessions. It also exercised replication behavior through both healthy startup and transient-outage recovery paths, giving a broad read on reliability under routine and edge-case conditions.

Safe to merge — the exercised core paths remained stable, and no failing result was attributed to this PR. The only observed defect is in an existing outage-recovery edge case in replication rather than a newly introduced regression, so it is a follow-up reliability concern rather than a merge blocker for this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Engine	Catalog introspection and schema-qualified versus unqualified relation lookups both returned consistent results in a direct PostgreSQL session, so the compatibility check passed.
✅	—	Query	Prepared-statement bind handling is implemented and the containerized regression re-run passed, including incompatible-type bind reuse returning a SQL error while the suite and session remained healthy.
✅	—	Replica	With a complete replication configuration and an initialized logical slot, the server reached readiness and started logical replication in the background as expected.
✅	—	Startup	With a clean data directory and default credentials, the server accepted a postgres connection, returned select 1, and listed the postgres database as available immediately after startup.
⚠️		Replica	The replicator swallows retryable connection/process errors and immediately re-enters beginReplication, creating repeated reconnect cycles that can persist without converging or surfacing a terminal error to server control flow.

Additional Findings Details

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

🟠 Replication reconnect loop does not converge after transient outages

• Severity: High
• Description: The replicator swallows retryable connection/process errors and immediately re-enters beginReplication, creating repeated reconnect cycles that can persist without converging or surfacing a terminal error to server control flow.
• Impact: Replication can get stuck in repeated reconnect attempts after a transient primary outage, so WAL streaming may never settle back into a stable state. Operators may see the service keep running while replication health silently degrades without a clear terminal failure.
• Steps to Reproduce:
  1. Configure postgres_replication with valid server address, port, database, user, password, and slot name, then start the server.
  2. Allow replication to begin and confirm initial logical replication startup logs are emitted.
  3. Introduce a transient primary outage by stopping and restarting the primary container, then restore connectivity.
  4. Observe repeated Error ... Retrying and Starting logical replication log sequences instead of sustained convergence or a terminal replication failure.
• Stub / mock content: The run used QA-only setup adjustments: SCRAM authentication was disabled for local SQL flow testing, replication targeted a local primary container, and the replication host was patched to 172.17.0.1 for nested-container networking.
• Code Analysis: In server/logrepl/replication.go, handleErrWithRetry increments connErrCnt for selected errors but returns nil while under maxConsecutiveFailures (lines 211-223), so the outer for-loop continues and immediately retries beginReplication when primaryConn is nil (lines 256-274). The counter is reset to 0 on any successful pass through handleErrWithRetry(err=nil) (lines 224-226), which allows intermittent progress to prolong churn under flapping conditions. Runtime evidence matches this path: REPLICA-2 logs show repeated Error: write failed ... Retrying followed by fresh Starting logical replication/Logical replication started cycles after transient outages. Separately, startup launches replication with go replicator.StartReplication(...) in server/server.go (line 269) without handling returned errors, so terminal replication failure is not propagated to startup control flow.

Evidence Package

• text/REPLICA-2/replication-reconnect-loop-evidence.txt — 3 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18269	18270
Failures	23821	23820
Partial Successes1	5334	5334

	Main	PR
Successful	43.4046%	43.4070%
Failures	56.5954%	56.5930%

${\color{lightgreen}Progressions (1)}$

json_encoding

QUERY: SELECT '"\u0000"'::json;

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. ↩

[github-actions]

This PR has been superseded by #2856