[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	1958.01/s	1942.20/s	-0.9%
groupby_scan_postgres	130.04/s	130.42/s	+0.2%
index_join_postgres	670.27/s	672.72/s	+0.3%
index_join_scan_postgres	863.25/s	860.80/s	-0.3%
index_scan_postgres	25.21/s	25.30/s	+0.3%
oltp_delete_insert_postgres	831.49/s	818.17/s	-1.7%
oltp_insert	711.65/s	711.01/s	-0.1%
oltp_point_select	3060.66/s	3061.29/s	0.0%
oltp_read_only	3049.66/s	3063.09/s	+0.4%
oltp_read_write	2176.48/s	2358.99/s	+8.3%
oltp_update_index	716.06/s	726.33/s	+1.4%
oltp_update_non_index	774.93/s	793.21/s	+2.3%
oltp_write_only	1745.15/s	1806.09/s	+3.4%
select_random_points	1896.89/s	1911.97/s	+0.7%
select_random_ranges	1137.33/s	1119.98/s	-1.6%
table_scan_postgres	24.01/s	23.53/s	-2.0%
types_delete_insert_postgres	794.82/s	797.90/s	+0.3%
types_table_scan_postgres	8.28/s	8.46/s	+2.1%

[github-actions]

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

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

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

subselect

QUERY:          select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);
RECEIVED ERROR: timeout during Receive

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

[itoqa]

Commit: 6356cc9: 8 test cases ran, 0 failed ❌, 6 passed ✅, 2 additional findings ⚠️.

Summary

Across 8 total test cases, 6 passed and 2 failed, showing generally stable behavior for core SQL execution, malformed statement handling, server bootstrap/default database creation, replication boundary checks, and locale/regex semantics, with sessions remaining healthy after expected compile or syntax errors. The most important findings were two real defects: malformed PostgreSQL bind payloads can trigger a recovered panic (index out of range) instead of a deterministic bind-validation error (high severity), and startup with missing replication slot_name can log a required-field error yet still exit with code 0 (medium severity), creating misleading success signals for automation and operations.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Engine	Plain SELECT returned all 200 fixture rows in order with correct totals.
✅	—	Engine	Malformed SQL returned a syntax error, and the same session immediately handled SELECT 1.
✅	—	Locale	Invalid regex inputs returned compile errors, and the same SQL session remained healthy for follow-up queries.
✅	—	Locale	Locale/collation setup and regex matrix checks preserved expected outputs and error classes for equivalent SQL semantics.
✅	—	Server	First startup created and exposed the default postgres database as expected.
✅	—	Server	Replication boundary behavior matched expectations across nil, partial, and full configs.
⚠️		Engine	The server should return a deterministic bind-validation error for malformed parameter counts, but it instead hits a recovered panic (index out of range [1] with length 1) during bind conversion.
⚠️		Server	The process emits postgres replication slot name must be specified and not empty for replication, but the command still returns exit code 0 instead of failing startup with a non-zero code.

Additional Findings Details

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

🟠 Malformed bind payload triggers panic

• Severity: High
• Description: The server should return a deterministic bind-validation error for malformed parameter counts, but it instead hits a recovered panic (index out of range [1] with length 1) during bind conversion.
• Impact: Malformed client bind payloads can trigger panic handling on a core query path, producing unstable error behavior in a high-criticality workflow. While the session may survive, this still creates unsafe request handling and merge risk for production traffic.
• Steps to Reproduce:
  1. Connect via PostgreSQL wire protocol and prepare a statement expecting one parameter.
  2. Send a bind payload containing extra parameter values relative to the prepared statement type list.
  3. Observe the server response and run a follow-up SELECT 1 in the same session.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: I reviewed server/doltgres_handler.go and server/connection_handler.go. convertBindParameters iterates over incoming bind values and directly indexes types[i] with no bounds check, so malformed payloads with more values than type descriptors can panic before a deterministic validation error is returned.

🟡 Startup reports replication validation but exits successfully

• Severity: Medium
• Description: The process emits postgres replication slot name must be specified and not empty for replication, but the command still returns exit code 0 instead of failing startup with a non-zero code.
• Impact: Automation and operators can misclassify an invalid replication configuration as a successful startup. This weakens startup safety checks for a core server workflow and can hide misconfiguration until later failures.
• Steps to Reproduce:
  1. Provide postgres_replication config with database, user, password, and port but omit slot_name.
  2. Start doltgres with this configuration.
  3. Observe the missing slot_name validation message and then check that the command exits with status 0.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: I inspected server/server.go and confirmed replication validation occurs in startReplication, which returns an error for missing slot_name, and runServer propagates that error after server startup work has already run. This aligns with runtime evidence showing the validation message appears while the command still reports success.

Tip

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

[github-actions]

This PR has been superseded by #2844