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

[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
Total	42090	42090
Successful	19290	19289
Failures	22800	22801
Partial Successes1	5459	5459

	Main	PR
Successful	45.8304%	45.8280%
Failures	54.1696%	54.1720%

${\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: f9dab47: 14 test cases ran, 12 passed ✅, 2 additional findings ⚠️.

Summary

Coverage spans core database behavior, including ordinary reads and writes, transaction recovery, versioned branches, reload persistence, schema metadata, and sequence allocation across sessions and overloads. It also exercises edge and concurrency conditions, including bounded sequences, failed writes, concurrent allocations, and prepared-query compatibility; the tested behavior is broadly healthy, with a few known capability and concurrency gaps.

Safe to merge — neither observed failure is attributable to this PR, and the dependency-focused change introduces no identified regression or merge-blocking behavior. The unrelated prepared-query limitation and concurrent sequence-state defect are medium-severity follow-up findings for the product, not reasons to block this merge.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The sequence returned 1, 2, and 3, then rejected another request after reaching its maximum value. The earlier errors came from malformed SQL quoting and an invalid catalog check, not from the sequence behavior.
✅	—	General	Switching between branches kept table rows and catalog columns in sync. The alternate branch showed two rows and three columns, while the main branch showed one row and two columns.
✅	—	General	A clean retry check showed that a sequence write error is returned to the client before any sequence value is reported. The earlier errors came from incorrectly quoted SQL, so the persistence-failure scenario was not actually triggered.
✅	—	General	Reloading the database kept the committed row, working row, staged status, branch references, and commit history unchanged.
✅	—	Connection	After a malformed SQL statement, the connection blocked the next query until rollback. ROLLBACK removed the uncommitted row, kept the committed row, and allowed normal queries to continue.
✅	—	Integrity	The committed row stayed present after a new working row was added and staged. Switching to a new branch and back to the main branch kept both rows and the staged change available.
✅	—	Integrity	The administrative integrity check scanned both branch heads and found no corrupt rows or adaptive values in the reachable data.
✅	—	Rev	The updated Dolt module resolved at the requested version, all modules passed verification, and every package in the repository test suite completed successfully.
✅	—	Sequence	A sequence created in a named schema returned 1 from the first session and 2 from a second session using the schema search path. The earlier errors came from broken SQL quoting and rolled-back setup, and the clean re-run completed successfully.
✅	—	Sequence	The text and regclass forms returned successive values from the same sequence. An unknown name returned the expected sequence-does-not-exist error without allocating a value.
✅	—	Sql	The database returned the two employees with the correct computed salaries, and both catalog queries showed the expected tables and columns.
✅	—	Sql	Switching between the main branch and a second branch showed the rows saved on each selected version.
⚠️		General	Concurrent calls returned unique values 1 through 10, but the sequence read back from the catalog had last value 2. The next allocation returned 12, showing that durable sequence progress was not recorded consistently.
⚠️		Connection	The simple query returned the expected row, and commit and rollback behaved correctly. The required PREPARE command returned 'PREPARE is not yet supported', EXECUTE returned 'EXECUTE is not yet supported', and the named prepared statement did not exist.

Additional Findings Details

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

🟡 Concurrent sequence calls lose durable progress

• Severity: Medium
• Description: Concurrent calls returned unique values 1 through 10, but the sequence read back from the catalog had last value 2. The next allocation returned 12, showing that durable sequence progress was not recorded consistently.
• Impact: Concurrent clients can receive unique sequence values while the database saves an older sequence position. Applications and tools that read the sequence state may see incorrect progress, and later allocations can be out of sync with that saved state.
• Steps to Reproduce:
  1. Create a sequence named race_seq with START 1.
  2. Use five independent clients to call nextval('race_seq'::text) and five independent clients to call nextval('race_seq'::regclass) at the same time.
  3. Confirm that the ten calls return unique values through 10.
  4. Query pg_catalog.pg_sequences for race_seq and compare last_value with the highest value returned by the clients.
  5. Call nextval('race_seq'::text) once more and compare that value with the stale catalog value.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: Both overloads in server/functions/nextval.go call the shared nextval function (lines 88-104 and 107-124). That function obtains a SequenceTracker, resolves the sequence, calls ait.Next at lines 70-73, and then calls collection.SetVal at lines 75-78 as a separate state update. Under concurrent sessions, the tracker can allocate distinct values while each request persists state derived from its own view; those separate updates permit a stale lower value to become the durable last-writer state. The re-execution observed exactly this split: all ten allocations were unique, but pg_sequences returned last_value=2 and the next call returned 12. The catalog path supports that interpretation: cachePgSequences stores the sequence object at server/tables/pgcatalog/pg_sequence.go:75-96, and pg_sequences.go:104-110 computes last_value from that object's Current and Increment fields. A minimal fix is to make allocation and durable update one concurrency-safe tracker operation, or otherwise serialize/merge the SetVal persistence for a sequence so a completed allocation cannot overwrite a newer durable value with an older state.

Evidence Package

• text/BF-RACE-1/BF-RACE-1-concurrent-readback.txt — 2 KB

🟡 Prepared SQL queries are rejected

• Severity: Medium
• Description: The simple query returned the expected row, and commit and rollback behaved correctly. The required PREPARE command returned 'PREPARE is not yet supported', EXECUTE returned 'EXECUTE is not yet supported', and the named prepared statement did not exist.
• Impact: Clients that use SQL PREPARE and EXECUTE cannot run those parameterized queries. Other queries and transaction commits continue to work.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL service as the postgres user.
  2. Create a table with an integer key and text value.
  3. Run a simple SELECT, then issue PREPARE get_value(integer) AS SELECT value FROM the table WHERE id = $1.
  4. Run EXECUTE get_value(1) and check whether the prepared query returns its row.
  5. Run the transaction commit and rollback checks and confirm that those checks pass while the prepared query still fails.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The production SQL conversion path is conclusively incomplete for this feature. In server/ast/prepare.go, nodePrepare at lines 24-30 returns nil for a nil AST, but for every non-nil *tree.Prepare it immediately returns NotYetSupportedError("PREPARE is not yet supported") without creating a statement or registering it. This explains the first runtime error and prevents the subsequent SQL EXECUTE from finding the requested statement. The PostgreSQL extended-query protocol is a separate path: ConnectionHandler.handleParse in server/connection_handler.go:656-729 converts the query, calls DoltgresHandler.ComPrepareParsed, and stores the protocol prepared statement; ComPrepareParsed in server/doltgres_handler.go:203-249 prepares and analyzes that protocol query. That separate implementation does not remove or bypass the SQL AST nodePrepare rejection. The PR context shows only go.mod and go.sum changes: the Dolt module version is bumped and an indirect puddle entry is adjusted. No changed line covers server/ast/prepare.go or a targeted compatibility shim. The smallest practical fix is to implement SQL PREPARE AST conversion and execution in the existing prepared-statement path, or explicitly route SQL PREPARE/EXECUTE into the already supported protocol statement machinery; changing unrelated dependency declarations will not fix this behavior.

Evidence Package

• text/CONNECTION-1/CONNECTION-1-prepared-query-run.txt — 2 KB

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	77.19	75.82	-1.77
index_join_postgres	2.22	2.22	0.0
index_join_scan_postgres	1.61	1.61	0.0
index_scan_postgres	467.3	475.79	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	467.3	467.3	0.0
types_table_scan_postgres	1170.65	1170.65	0.0

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.67	0.0
oltp_insert	3.3	3.3	0.0
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	6.91	0.0
types_delete_insert_postgres	7.17	7.17	0.0