[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	1880.45/s	1883.00/s	+0.1%
groupby_scan_postgres	128.37/s	126.17/s	-1.8%
index_join_postgres	679.77/s	677.46/s	-0.4%
index_join_scan_postgres	831.26/s	828.77/s	-0.3%
index_scan_postgres	29.93/s	29.90/s	-0.2%
oltp_delete_insert_postgres	783.58/s	759.57/s	-3.1%
oltp_insert	634.50/s	656.80/s	+3.5%
oltp_point_select	3440.41/s	3451.97/s	+0.3%
oltp_read_only	3283.27/s	3343.52/s	+1.8%
oltp_read_write	2493.40/s	2545.28/s	+2.0%
oltp_update_index	708.67/s	690.47/s	-2.6%
oltp_update_non_index	718.21/s	734.09/s	+2.2%
oltp_write_only	1779.55/s	1770.76/s	-0.5%
select_random_points	1948.80/s	1994.23/s	+2.3%
select_random_ranges	1521.34/s	1547.71/s	+1.7%
table_scan_postgres	28.03/s	27.92/s	-0.4%
types_delete_insert_postgres	749.14/s	740.45/s	-1.2%
types_table_scan_postgres	12.70/s	12.77/s	+0.5%

[itoqa]

Commit: 0d55b73: 16 test cases ran, 15 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans core database behavior including reads and writes, transactions, concurrent sessions, catalog and type handling, schema and object lifecycle, authentication and configuration validation, restart and data persistence, corruption safeguards, and concurrent updates. It includes normal workflows, boundary and invalid-input cases, recovery scenarios, and adversarial concurrency and storage-integrity checks, with broad overall health aside from a pre-existing metadata issue.

Safe to merge — the sole failure is a medium-severity, pre-existing catalog issue caused by concurrent user-defined-type changes and is explicitly unrelated to this PR; no regression or PR-attributable failure was found. It remains a flag for later because it can disrupt metadata discovery, but it is not a merge blocker for this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Query	SELECT, INSERT, UPDATE, DELETE, transaction commit and rollback, and concurrent session isolation all worked correctly. PREPARE and EXECUTE returned explicit not-supported errors from unchanged doltgresql code, so this pre-existing limitation is not a regression from the dependency update.
✅	—	Query	Catalog metadata and casts were verified successfully. pg_type returned the expected built-in type rows and metadata, pg_class returned stable catalog and user-table entries, catalog joins resolved pg_catalog correctly, regtype and regclass casts round-tripped to the expected names and OIDs, and invalid relation names returned a clean error without mutating later results. The recorded run also identified that regnamespace casting is not supported, so that check used the raw namespace OID.
✅	—	Query	A failed foreign-key DDL and a syntax-error DDL were followed by ROLLBACK without contaminating the session. Valid DDL then committed, remained visible to a second session, and persisted after restart; the run also observed that separate successful DDL is auto-committed rather than reverted by ROLLBACK.
✅	—	Root	Created two schemas, tables, and a sequence, then restarted doltgres on the same data directory. Schema and table catalogs remained available in sorted order, the sequence advanced from 1 to 2, and inserts and reads succeeded in both schemas after restart.
✅	—	Root	Schema validation and drop behavior matched expectations: empty and case-insensitive duplicate names were rejected, case-insensitive dropping removed Sales, populated Reports was protected by its table dependency, and the final empty drop succeeded.
✅	—	Root	The local lifecycle check created a sequence, table, view, function, trigger, and user-defined type, then confirmed that they remained usable after restart. Sequence values, table and view data, function results, trigger output, type resolution, Dolt branches, and commit history were preserved; functions and triggers were verified through execution and status tracking because their catalog views are not populated.
✅	—	Server	Doltgres started without a YAML configuration, listened on TCP port 5432, authenticated the postgres user with the configured environment password, executed SELECT queries, listed databases, and accepted a database write operation.
✅	—	Server	Malformed YAML and YAML containing an unknown field were rejected before the server started, and port 5432 remained unavailable in both cases.
✅	—	Server	The entrypoint retried Doltgres while the malformed YAML prevented port 5432 from opening. Replacing the configuration without recreating the data directory allowed the next retry to start the listener, authenticate successfully, and create, insert, and read a table from the preserved data directory.
✅	—	Storage	An existing repository was opened, a new employee row was committed, and both the original and new rows remained available after restarting Doltgres with the same data directory.
✅	—	Storage	A corrupted journal payload was rejected at startup with an explicit CRC checksum error and possible-data-loss warning. The manifest root hash and journal file size remained unchanged, and the committed rows were readable after the original bytes were restored and the server restarted.
✅	—	Storage	Two concurrent PostgreSQL sessions committed independent changes successfully, and after restart the renamed table, foreign key, inserted row, and updated row were all still present.
✅	—	Storage	After restart, the committed schema remained consistent: st4_parent and its primary key persisted, st4_child and its foreign key were removed together, reads of the dropped table failed explicitly, and a new foreign key still rejected an invalid parent reference.
✅	—	Type	The domain and composite types retained their catalog identities and metadata after restart; stored rows, array and composite casts, field access, and the domain check constraint all continued to work.
✅	—	Type	Nulls, valid scalars, boundary values, empty arrays, and composite values were stored and round-tripped successfully. Invalid values were rejected without changing the six valid rows, and subsequent casts across scalar, domain, array, and composite types continued to work.
⚠️		Type	The concurrent DDL produced partial transaction behavior: one CREATE TYPE reported success but its following CREATE TABLE could not resolve the newly created type. Subsequent pg_type queries failed with 'unable to resolve type coord_t during deserialization', and the same errors persisted after restart, contrary to the expectation that each surviving type has one durable definition resolvable by the catalog.

Additional Findings Details

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

🟡 Concurrent type DDL corrupts catalog lookups

• Severity: Medium
• Description: The concurrent DDL produced partial transaction behavior: one CREATE TYPE reported success but its following CREATE TABLE could not resolve the newly created type. Subsequent pg_type queries failed with 'unable to resolve type coord_t during deserialization', and the same errors persisted after restart, contrary to the expectation that each surviving type has one durable definition resolvable by the catalog.
• Impact: Concurrent changes to related user-defined types can leave the type catalog unable to deserialize referenced types, breaking catalog-driven introspection and ORM type discovery. Direct table access and casts continue to work, but the persistent metadata failure remains until the corrupted type-cache state is repaired.
• Steps to Reproduce:
  1. Create a composite type coord_t and a table that stores values of that type.
  2. Run concurrent transactions that redefine or use coord_t while creating the related extended_coord_t type and dependent tables.
  3. Commit both transactions and query pg_type for coord_t, extended_coord_t, or a type-name pattern.
  4. Restart Doltgres with the same data directory and repeat the pg_type queries.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: server/types/serialization.go:279-288 calls TypeCollection.GetType while recursively deserializing an unresolved type and turns a nil result into the observed 'unable to resolve type' error. core/typecollection/typecollection.go:159-219 reads the type from accessedMap, initCache, or the underlying map and deserializes it, while writeCache at lines 505-529 writes cached types through a map editor and replaces the underlying map only after Flush; the reproduced concurrent DDL state is consistent with a cache/map entry that cannot be deserialized even though direct table and cast paths can still resolve coord_t. The smallest practical fix is to make concurrent type-cache updates and reads publish a complete, consistently deserializable map entry before it can be observed, while preserving the existing serialization error for genuinely missing types.

Evidence Package

• text/TYPE-3/TYPE-3-concurrent-ddl-catalog.log — 3 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18317	18317
Failures	23773	23773
Partial Successes1	5276	5276

	Main	PR
Successful	43.5187%	43.5187%
Failures	56.4813%	56.4813%

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

[github-actions]

This PR has been superseded by #2946