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

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

[itoqa]

Commit: f1a3a0c: 11 test cases ran, 10 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans core database behavior across normal reads and writes, schema changes, transactions, reconnects, concurrent updates, retries, constraints, data types, branch isolation, and dependency/build health. It also exercises edge and failure-recovery paths, including invalid queries, rejected data, duplicate writes, transaction rollback, and concurrent activity, with the overall application behavior remaining healthy.

Safe to merge — the only failure is a high-severity, pre-existing database retry defect unrelated to this pull request, with no regressions or new PR-attributable failures. It is a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	Generated IDs stayed unique after the table changed, the new default remained active after reconnect, and invalid data was rejected. The final committed state contained all valid rows with no pending changes.
✅	—	General	A PostgreSQL client returned the expected rows and update count, reported the invalid query clearly, and answered the next valid query on the same connection.
✅	—	General	Reconnecting starts a new database session, so it correctly opens on the main branch. Selecting the feature branch again before reading its rows is required, and the feature data was not shown to be lost.
✅	—	General	Two sessions updated different rows, and both changes were still present after the commits and final readback.
✅	—	General	Retrying the same insert returned a clear duplicate-key error, and the table kept exactly one row after the commit.
✅	—	Query	The database returned the expected rows and calculated values, accepted an insert and update, completed a table creation, and returned the saved data and table details.
✅	—	Rev	The database accepted primary keys, foreign keys, NULL values, and numeric values. Joins and totals returned the expected results, and an invalid foreign-key insert was rejected without adding a row.
✅	—	Rev	The local database answered a smoke query, and the repository's module checks and full test suite passed twice. The dependency upgrade did not cause checksum, compile, API, or test failures.
✅	—	Storage	The inserted row was readable before the commit and remained available after the connection was closed and reopened.
✅	—	Transaction	After a failed statement, the transaction was rolled back successfully. A later insert committed and was still available after reconnect, while the invalid attempt was gone.
⚠️		General	The retry caused a server panic instead of completing the parameterized operation, and the expected replacement row was missing after reconnect.

Additional Findings Details

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

🟠 Retry loses data after transaction error

• Severity: High
• Description: The retry caused a server panic instead of completing the parameterized operation, and the expected replacement row was missing after reconnect.
• Impact: A client retry of a parameterized database operation can crash the bind path and fail to save the replacement row. Users relying on this transaction flow may lose a write and must retry or recover it themselves.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL server and create a table for a parameterized insert.
  2. Start a transaction, execute the parameterized insert, then submit an invalid SQL statement.
  3. Roll back the transaction, reuse the same connection, and execute the parameterized insert with a new value.
  4. Commit, reconnect, and query the table to verify that the replacement row was saved.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The recorded failure names DoltgresHandler.convertBindParameters and reports an index-out-of-range panic while handling a recovered Bind request. In server/doltgres_handler.go, convertBindParameters first extends formatCodes but never validates that the types slice has at least one entry for every supplied value. The loop at lines 318-340 iterates over values, then unconditionally reads types[i] at line 320 before converting the value. If a PostgreSQL client sends a value while the prepared statement's inferred or declared type list is empty or shorter than the value list, this production path panics rather than returning a protocol error. ComBind calls this function at lines 122-127, and handleBind passes the prepared statement's BindVarTypes and the wire message's Parameters at server/connection_handler.go lines 785-795. The panic is caught by receiveMessage at lines 399-412, which emits the recovered-panic error and ends message processing, explaining the observed protocol failure and missing committed row. The smallest practical fix is to validate len(types) against len(values) before the loop and return a client-visible bind error when a parameter type is unavailable; the handler should then complete the protocol's error/sync path without indexing beyond the type slice.

Evidence Package

• text/BF-FAIL-2/BF-FAIL-2-bind-retry-evidence.txt — 3 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	19252	19251
Failures	22838	22839
Partial Successes1	5465	5465

	Main	PR
Successful	45.7401%	45.7377%
Failures	54.2599%	54.2623%

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

[coffeegoddd]

@coffeegoddd DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.52	2.43	-3.57
groupby_scan_postgres	77.19	77.19	0.0
index_join_postgres	2.22	2.22	0.0
index_join_scan_postgres	1.58	1.55	-1.9
index_scan_postgres	475.79	484.44	1.82
oltp_point_select	0.36	0.36	0.0
oltp_read_only	6.32	6.32	0.0
select_random_points	0.7	0.7	0.0
select_random_ranges	1.01	1.01	0.0
table_scan_postgres	484.44	484.44	0.0
types_table_scan_postgres	1191.92	1213.57	1.82

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.67	0.0
oltp_insert	3.3	3.36	1.82
oltp_read_write	13.22	13.22	0.0
oltp_update_index	3.55	3.55	0.0
oltp_update_non_index	3.25	3.25	0.0
oltp_write_only	6.91	7.04	1.88
types_delete_insert_postgres	7.17	7.17	0.0

[github-actions]

This PR has been superseded by #3227