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

[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	1826.94/s	1825.80/s	-0.1%
groupby_scan_postgres	134.04/s	135.29/s	+0.9%
index_join_postgres	646.05/s	638.14/s	-1.3%
index_join_scan_postgres	789.10/s	787.18/s	-0.3%
index_scan_postgres	24.54/s	24.80/s	+1.0%
oltp_delete_insert_postgres	778.64/s	781.90/s	+0.4%
oltp_insert	694.19/s	684.57/s	-1.4%
oltp_point_select	2858.31/s	2836.81/s	-0.8%
oltp_read_only	2857.25/s	2892.24/s	+1.2%
oltp_read_write	2270.55/s	2265.30/s	-0.3%
oltp_update_index	707.37/s	706.73/s	-0.1%
oltp_update_non_index	750.61/s	734.57/s	-2.2%
oltp_write_only	1731.40/s	1727.31/s	-0.3%
select_random_points	1840.61/s	1841.93/s	0.0%
select_random_ranges	1072.55/s	1074.24/s	+0.1%
table_scan_postgres	23.18/s	23.48/s	+1.2%
types_delete_insert_postgres	680.70/s	${\color{lightgreen}755.14/s}$	${\color{lightgreen}+10.9\%}$
types_table_scan_postgres	8.10/s	8.25/s	+1.8%

[itoqa]

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

Summary

This run exercised core database behavior across normal SQL operations and protective error handling, including data ingest, startup with defaults, and schema safety checks, and those product-level flows remained healthy. It also covered a replication fault path that reflects a known no-progress failure mode under upstream disruption rather than a new regression in this change.

Safe to merge — the exercised functionality for this PR’s scope behaved as expected, and no new regressions were found in changed areas. The only flagged issue is a high-severity but pre-existing replication edge-case in an unchanged path, so it is a follow-up reliability concern rather than a merge blocker for this PR.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Hook	DROP TABLE was correctly rejected when another table column depended on the dropped table's row type, and both tables remained available.
✅	—	Query	COPY FROM STDIN loaded all streamed rows exactly once, and the connection returned to normal query mode after CopyDone.
✅	—	Schema	Creating a view with the same name as an existing table correctly returned a relation-already-exists error, and the original table and data remained intact.
✅	—	Server	Source review and re-execution show the no-config startup path correctly falls back to defaults and serves SQL once readiness is reached; the earlier failure came from connecting before the server was ready.
⚠️		Replication	The replication loop treats the context-deadline branch as a nil-return path, which can skip retry escalation and allow repeated no-progress behavior instead of bounded failure handling.

Additional Findings Details

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

🟠 Replication receive timeout path can mask fatal stream errors

• Severity: High
• Description: The replication loop treats the context-deadline branch as a nil-return path, which can skip retry escalation and allow repeated no-progress behavior instead of bounded failure handling.
• Impact: Replication can stall indefinitely instead of surfacing a failure, leaving the replica out of date while the source continues to advance. Users relying on the replica may read stale data and believe replication is healthy when it is not.
• Steps to Reproduce:
  1. Configure source and replica logical replication and confirm baseline WAL position.
  2. Induce a hard source-side failure condition and observe multiple receive windows.
  3. Observe that WAL position and replica rows do not advance while the loop continues without escalating to a terminal replication error.
• Stub / mock content: The run used a local QA setup with a containerized source/replica environment, induced source-container failure, and temporary authentication disablement for test connectivity; no production systems were involved.
• Code Analysis: In StartReplication, ReceiveMessage runs with a deadline context (lines 288-293). The select branch for ctx.Done() returns nil directly (lines 300-303), bypassing handleErrWithRetry at lines 210-229 where consecutive failures are counted and escalated. Only msgAndErr.err enters Timeout()/retry classification (lines 307-313), so the ctx.Done path can avoid bounded escalation and keep looping during non-progress conditions. PR diff evidence shows only dependency file updates (go.mod, go.sum) and no changed lines in this replication control flow.

Evidence Package

• text/REPLICATION-1/REPLICATION-1-receive-timeout-stall-evidence.txt — 2 KB

Tip

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

[github-actions]

This PR has been superseded by #2854

[github-actions]

	Main	PR
Total	42090	42090
Successful	18270	18271
Failures	23820	23819
Partial Successes1	5334	5334

	Main	PR
Successful	43.4070%	43.4094%
Failures	56.5930%	56.5906%

${\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. ↩