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

[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	1846.80/s	1833.99/s	-0.7%
groupby_scan_postgres	135.87/s	136.69/s	+0.6%
index_join_postgres	646.85/s	650.90/s	+0.6%
index_join_scan_postgres	799.34/s	801.18/s	+0.2%
index_scan_postgres	24.85/s	24.68/s	-0.7%
oltp_delete_insert_postgres	768.11/s	747.27/s	-2.8%
oltp_insert	653.09/s	680.32/s	+4.1%
oltp_point_select	2930.13/s	2913.53/s	-0.6%
oltp_read_only	2942.59/s	2921.71/s	-0.8%
oltp_read_write	2331.84/s	2176.27/s	-6.7%
oltp_update_index	694.92/s	697.40/s	+0.3%
oltp_update_non_index	731.41/s	751.27/s	+2.7%
oltp_write_only	1726.38/s	1726.04/s	-0.1%
select_random_points	1830.13/s	1852.94/s	+1.2%
select_random_ranges	1097.09/s	1097.28/s	0.0%
table_scan_postgres	23.49/s	23.05/s	-1.9%
types_delete_insert_postgres	742.87/s	745.67/s	+0.3%
types_table_scan_postgres	8.10/s	7.93/s	-2.1%

[itoqa]

Commit: 2a72e56: 8 test cases ran, 0 failed ❌, 7 passed ✅, 1 additional finding ⚠️.

Summary

Across 8 total test cases, 7 passed and 1 failed, indicating the run was largely successful with regressions checks for SQL execution, protocol behavior, collation handling, and startup sanity mostly holding. The most important finding was a high-severity startup reliability bug where the server can report readiness and accept connections even if replication startup fails (because replication is launched asynchronously and errors are not propagated), while all other validated behaviors remained correct, including RETURNING row payloads vs non-RETURNING command tags, protected-path COPY FROM rejection, zero/empty OID bind inference, and driver metadata/value alignment.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Collation	Legacy fixture-backed server handled collation-sensitive queries with default-compatible ordering and exact-match behavior.
✅	—	Collation	In-container psycopg2 and pg8000 probes showed matching field metadata and decoded values for domain/text/regex expressions.
✅	—	Protocol	COPY FROM rejected sensitive system path access and left the table unchanged.
✅	—	Protocol	Prepared statements executed correctly when parameter OIDs were empty or zero.
✅	—	Query	INSERT with RETURNING returned row data and persisted state correctly.
✅	—	Query	INSERT/UPDATE variants preserved stable row-vs-command-tag response shapes.
✅	—	Startup	Server startup completed and accepted a live SELECT 1 query from localhost.
⚠️		Startup	The server reports readiness and accepts connections before replication startup success is known; expected behavior is controlled startup failure (or explicit unhealthy status) when replication initialization fails.

Additional Findings Details

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

🟠 Server reports ready before replication startup succeeds

• Severity: High
• Description: The server reports readiness and accepts connections before replication startup success is known; expected behavior is controlled startup failure (or explicit unhealthy status) when replication initialization fails.
• Impact: Operators can treat an unhealthy replica as ready, which can lead to incorrect rollout and monitoring decisions in a core startup workflow. This affects replication-enabled deployments without a practical workaround other than changing startup behavior.
• Steps to Reproduce:
  1. Configure postgres_replication with valid fields but an unreachable upstream server address.
  2. Start the server and observe that it reports readiness and accepts connections.
  3. Inspect the startup and replication code paths to confirm replication startup runs asynchronously and its returned errors are not propagated to startup failure.
• Stub / mock content: Authentication checks were temporarily bypassed for stable local connections, and replication was intentionally pointed at an unreachable upstream to verify startup failure handling.
• Code Analysis: Reviewed server/server.go startup control flow and server/logrepl/replication.go replication initialization. Runtime evidence in the test artifacts matches the code path: readiness is emitted and connections are accepted even though replication startup can fail asynchronously.

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18269	18268
Failures	23821	23822
Partial Successes1	5333	5333

	Main	PR
Successful	43.4046%	43.4022%
Failures	56.5954%	56.5978%

${\color{red}Regressions (1)}$

random

QUERY:          (SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1);
RECEIVED ERROR: expected row count 0 but received 1

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 #2842