[auto-bump] [no-release-notes] Dolt dependency

[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]

Automated approval: validated dependency-only update.

[github-actions]

	Main	PR
Total	42090	42090
Successful	19905	19905
Failures	22185	22185
Partial Successes1	5450	5450

	Main	PR
Successful	47.2915%	47.2915%
Failures	52.7085%	52.7085%

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

copyselect

QUERY:          drop table test3;
RECEIVED ERROR: COPY DATA message received without a COPY FROM STDIN operation in progress

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

subselect

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

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: 85e5a7a: 14 test cases ran, 14 passed ✅.

Summary

Coverage spans core database behavior: ordinary and parameterized reads and writes, committed data and schema visibility, transaction commit and rollback handling, recovery after malformed or failed queries, concurrent updates, and historical data reads. It includes normal flows plus edge cases involving NULL and binary values, invalid input, retries, connection reuse, cross-connection visibility, and concurrent consistency.

Safe to merge — all exercised behaviors passed, with no regressions, new failures, or previously flagged failures attributable to this PR. No merge-blocking application issues were identified.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	Text, binary, and NULL parameters returned the right rows, and repeating the text value did not reuse stale data.
✅	—	General	The committed table kept its row data and updated column list after the schema change and a fresh connection.
✅	—	General	The malformed prepared statement returned an error, then the same connection returned Alice and Bob and passed a final framing check.
✅	—	General	Committed rows stayed visible, the rolled-back row stayed absent, and the same connection continued working after commands were issued in different orders.
✅	—	General	While one session committed updates, the other always saw a complete table state with matching rows and column details.
✅	—	General	A malformed query returned an error, then the same connection returned both employee rows and accepted a final query.
✅	—	Binding	The application supports text parameters through its PostgreSQL client protocol, and the matching row is returned with the value Alice. The recorded failure came from sending SQL PREPARE and EXECUTE commands, which is a different path from the extended protocol used for client parameter binding.
✅	—	Dolt	The employee rows were committed and could be read from the current branch. The table also appeared in the catalog with the expected table type.
✅	—	Results	The query returned Alice and Bob with ids 1 and 2 in ascending order.
✅	—	Rev	The reviewed Dolt and SQL engine versions resolved exactly, all module checksums were verified, and dependency cleanup made no file changes.
✅	—	Rev	All packages passed their tests and checks, and both production programs built successfully after the dependency update.
✅	—	Rev	The client connected successfully, ran ordinary and parameterized SQL, committed an update, and read the changed row from a second connection with the expected metadata.
✅	—	Rev	The duplicate insert returned an error, but the session recovered. A later valid insert committed, and another connection saw exactly the two valid rows.
✅	—	Rev	Two commits succeeded, the current table showed values 1 and 2, and the earlier snapshot showed only value 1. The same session also accepted another query afterward.

Tip

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

[coffeegoddd]

@coffeegoddd DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.43	2.43	0.0
groupby_scan_postgres	80.03	80.03	0.0
index_join_postgres	2.26	2.26	0.0
index_join_scan_postgres	1.64	1.64	0.0
index_scan_postgres	475.79	502.2	5.55
oltp_point_select	0.37	0.37	0.0
oltp_read_only	6.43	6.55	1.87
select_random_points	0.73	0.73	0.0
select_random_ranges	1.04	1.04	0.0
table_scan_postgres	475.79	511.33	7.47
types_table_scan_postgres	1191.92	1280.93	7.47

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.67	0.0
oltp_insert	3.36	3.36	0.0
oltp_read_write	13.46	13.46	0.0
oltp_update_index	3.55	3.55	0.0
oltp_update_non_index	3.25	3.25	0.0
oltp_write_only	7.04	7.04	0.0
types_delete_insert_postgres	7.17	7.17	0.0