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

[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	2492.92/s	2494.57/s	0.0%
groupby_scan_postgres	169.36/s	169.81/s	+0.2%
index_join_postgres	868.21/s	861.95/s	-0.8%
index_join_scan_postgres	1087.67/s	1101.04/s	+1.2%
index_scan_postgres	33.92/s	33.74/s	-0.6%
oltp_delete_insert_postgres	297.04/s	${\color{lightgreen}400.23/s}$	${\color{lightgreen}+34.7\%}$
oltp_insert	119.68/s	${\color{lightgreen}422.02/s}$	${\color{lightgreen}+252.6\%}$
oltp_point_select	3854.88/s	3844.01/s	-0.3%
oltp_read_only	3905.49/s	3953.44/s	+1.2%
oltp_read_write	1127.02/s	${\color{lightgreen}1779.70/s}$	${\color{lightgreen}+57.9\%}$
oltp_update_index	223.91/s	${\color{red}174.32/s}$	${\color{red}-22.2\%}$
oltp_update_non_index	281.92/s	${\color{red}194.70/s}$	${\color{red}-31.0\%}$
oltp_write_only	1359.10/s	${\color{red}1006.00/s}$	${\color{red}-26.0\%}$
select_random_points	2433.27/s	2453.17/s	+0.8%
select_random_ranges	1399.44/s	1419.73/s	+1.4%
table_scan_postgres	31.62/s	31.49/s	-0.5%
types_delete_insert_postgres	289.43/s	281.68/s	-2.7%
types_table_scan_postgres	11.10/s	11.24/s	+1.2%

[itoqa]

Commit: 55fa39f: 10 test cases ran, 0 failed ❌, 10 passed ✅, 0 additional findings ⚠️.

Summary

Coverage spans core database behaviors: authenticated and rejected login flows, prepared and returning query execution with metadata, data ingestion sequencing, and first-start initialization. It also exercises defensive edge cases around replication misconfiguration and startup failure handling, with overall behavior remaining stable and consistent.

Safe to merge — the run shows no regressions in primary query, authentication, ingestion, and startup paths, including negative and fail-closed scenarios. Observed outcomes align with expected behavior for both normal operation and misconfiguration edge cases, indicating low merge risk.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Handshake	Connected with valid postgres/password credentials and executed SELECT current_user successfully, demonstrating authenticated session and query execution.
✅	—	Handshake	Authentication correctly rejects a valid username when the password is wrong, and the session is denied before any SQL runs.
✅	—	Handshake	Failed login for an existing user with a wrong password and a nonexistent user returned the same client-visible authentication-denied shape apart from the username value.
✅	—	Ingestion	COPY #2 starts cleanly after CopyFail when the pending ErrorResponse and ReadyForQuery from the intentionally invalid extra CopyData frame are fully drained, so the earlier XX000 observation was a protocol-drain artifact rather than stale server COPY state leakage.
✅	—	Query	Prepared statement Parse, Describe, Bind, and Execute completed successfully with expected parameter metadata and result value 5, so no application defect was reproduced for this scenario.
✅	—	Query	INSERT INTO t_ret VALUES (1) RETURNING id returned one field description (id, int4 OID 23) and one row value (1), and persisted state readback confirmed the insert.
✅	—	Query	Prepared Parse/Describe for SELECT 1::bigint AS id returned the analyzed field metadata (id, bigint OID 20), and execution returned 1, so no production-code defect is evidenced for this case.
✅	—	Server	Started doltgres with an empty data directory and default credentials, then verified the default postgres database exists and accepts queries.
✅	—	Server	The blocked runner outcome was caused by local runtime unavailability, while source and retry evidence confirm the expected guard: startup emits a clear validation error when replication is enabled without slot_name and does not start replication.
✅	—	Server	With replication configured missing slot_name, startup emits the expected validation error and exits with status 1. Although logs briefly print 'Server ready,' repeated probes never establish a usable SQL connection, so the service fails closed rather than exposing a misleading healthy endpoint.

Tip

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

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