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

[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	4018.90/s	3972.33/s	-1.2%
groupby_scan_postgres	275.95/s	254.88/s	-7.7%
index_join_postgres	1193.64/s	1161.36/s	-2.8%
index_join_scan_postgres	1565.80/s	1545.45/s	-1.3%
index_scan_postgres	56.55/s	54.71/s	-3.3%
oltp_delete_insert_postgres	765.08/s	753.64/s	-1.5%
oltp_insert	644.49/s	625.27/s	-3.0%
oltp_point_select	7782.58/s	7810.23/s	+0.3%
oltp_read_only	7103.39/s	6974.92/s	-1.9%
oltp_read_write	3220.80/s	${\color{lightgreen}3657.95/s}$	${\color{lightgreen}+13.5\%}$
oltp_update_index	234.55/s	${\color{lightgreen}527.81/s}$	${\color{lightgreen}+125.0\%}$
oltp_update_non_index	253.78/s	${\color{lightgreen}682.25/s}$	${\color{lightgreen}+168.8\%}$
oltp_write_only	2156.43/s	2007.01/s	-7.0%
select_random_points	4145.56/s	4104.69/s	-1.0%
select_random_ranges	3022.92/s	3027.94/s	+0.1%
table_scan_postgres	55.51/s	55.68/s	+0.3%
types_delete_insert_postgres	877.85/s	832.48/s	-5.2%
types_table_scan_postgres	25.50/s	25.70/s	+0.7%

[github-actions]

	Main	PR
Total	42090	42090
Successful	18407	18406
Failures	23683	23684
Partial Successes1	5327	5327

	Main	PR
Successful	43.7325%	43.7301%
Failures	56.2675%	56.2699%

${\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: 0730e2e: 16 test cases ran, 15 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans core database behavior: creating and querying user-defined types and tables, transaction visibility and recovery from invalid operations, durable sequence generation under reconnects, restarts, concurrency, and storage faults, plus persistence of schema and relationship metadata across branches and server lifecycles. It also exercises adversarial concurrency and failure-recovery paths, with the application behavior broadly healthy aside from an unrelated concurrent type-creation correctness issue.

Safe to merge — the only failing behavior is a pre-existing, high-severity concurrency issue not attributable to this PR, with no new regressions or PR-related failures identified. It remains a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Engine	A type and a table were created in one session, then found and queried successfully from a second session.
✅	—	Engine	Creating a table that already exists showed the expected error. The same session then created a different table, inserted a row, and read it from the catalog successfully.
✅	—	Sequence	Committed generated IDs 101-103 continued as 104-105 after reconnect, so sequence values stayed unique and durable. An extra metadata lookup was unsupported, but it did not affect ID allocation.
✅	—	Sequence	The source code keeps an explicit sequence value when it is changed and writes that change into the database working state. The restart and branch check could not be completed because the local test service stopped, so this case needs a runnable local service for full runtime confirmation.
✅	—	Sequence	A sequence created in an open transaction stayed hidden from the other session. After commit, that session received 12 and a fresh connection received 13, confirming committed visibility and durable allocation.
✅	—	Sequence	Four clients committed 100 rows at the same time. Every row was present with a unique ID from 1 through 100, and the next generated ID was 101.
✅	—	Sequence	A forced storage write error was returned cleanly, and the sequence collection remained usable when storage became healthy again.
✅	—	Sequence	Rows 1 and 2 were still present after the local server restarted, and the next inserted row received id 3.
✅	—	Server	A fresh local server accepted a connection, used the default database, created a table, inserted a row, and returned it successfully.
✅	—	Server	A committed row was still available when a separate client reconnected to the configured data directory.
✅	—	Server	The replication-failure check could not run because the local test setup did not include the required fault fixture. Source review found that a replication startup error stops the listener before the server returns the error.
✅	—	Storage	The related tables were created, committed, and reopened successfully. The foreign-key constraint still points to the original parent table after reconnecting.
✅	—	Storage	The new mood type and its table stayed available after a commit, switching branches, returning to the main branch, and reconnecting.
✅	—	Storage	The storage fault could not be created in the local test environment, but source review shows a failed write leaves the original metadata unchanged. No phantom root or hash was found.
✅	—	Storage	The saved root hash, foreign-key link, and table list were unchanged after the server restarted.
⚠️		Engine	Both concurrent CREATE TYPE commands returned success. The catalog later contained one durable enum, and only a later retry returned the expected type-already-exists error; the losing concurrent command should have returned that error immediately.

Additional Findings Details

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

🟠 Concurrent type creation reports two successes

• Severity: High
• Description: Both concurrent CREATE TYPE commands returned success. The catalog later contained one durable enum, and only a later retry returned the expected type-already-exists error; the losing concurrent command should have returned that error immediately.
• Impact: When two clients create the same type at once, both may be told the operation succeeded even though only one type is saved. The losing client must discover the mismatch and retry after checking the catalog.
• Steps to Reproduce:
  1. Open two PostgreSQL sessions connected to the same database.
  2. In both sessions, submit CREATE TYPE batch_engine.engine3_status AS ENUM ('new', 'done') at the same time.
  3. Check both command results, then reconnect and query the type catalog.
  4. Submit the same CREATE TYPE statement again from a new session.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The production path has a check-then-insert race. In server/node/create_type.go:106-112, RowIter computes the type ID and calls collection.HasType before creating the type. If both sessions read the catalog before either mutation is visible, both pass this check. RowIter then calls collection.CreateType at server/node/create_type.go:145-158, including a second insertion for the generated array type. TypeCollection.CreateType in core/typecollection/typecollection.go:58-76 checks accessedMap and the underlying contents separately, then writes pgs.accessedMap[typ.ID] without a mutex or a compare-and-insert operation spanning the check and cache update. The staged entries are flushed later by writeCache in core/typecollection/typecollection.go:497-521, so persistence is not the point at which one CREATE TYPE statement is selected as the winner. The root update path in core/rootobject/collection.go:483-486 occurs after the collection mutation, which permits both statements to return success before durable conflict handling. The observed two successful responses followed by one durable enum and a later duplicate error is the expected result of this race. The smallest practical fix is to serialize the existence check and cache insertion for user-defined types, or provide an atomic collection-level create operation that returns ErrTypeAlreadyExists to the losing statement before it reports success; the generated array type must be included in the same guarded operation.

Evidence Package

• text/ENGINE-3/ENGINE-3-concurrent-sql.txt — 2 KB
• text/ENGINE-3/ENGINE-3-create-type-race.txt — 2 KB

Tip

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

[github-actions]

This PR has been superseded by #3077