[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
covering_index_scan_postgres	1973.37/s	1950.74/s	-1.2%
groupby_scan_postgres	116.53/s	121.42/s	+4.1%
index_join_postgres	649.77/s	649.81/s	0.0%
index_join_scan_postgres	795.61/s	797.57/s	+0.2%
index_scan_postgres	29.41/s	29.11/s	-1.1%
oltp_delete_insert_postgres	787.25/s	731.45/s	-7.1%
oltp_insert	666.53/s	661.24/s	-0.8%
oltp_point_select	3270.44/s	3254.66/s	-0.5%
oltp_read_only	3197.51/s	3187.70/s	-0.4%
oltp_read_write	2447.34/s	2462.50/s	+0.6%
oltp_update_index	693.26/s	706.23/s	+1.8%
oltp_update_non_index	752.96/s	735.91/s	-2.3%
oltp_write_only	1762.17/s	1729.70/s	-1.9%
select_random_points	1988.58/s	1968.90/s	-1.0%
select_random_ranges	1500.41/s	1509.38/s	+0.5%
table_scan_postgres	27.82/s	27.59/s	-0.9%
types_delete_insert_postgres	733.22/s	742.53/s	+1.2%
types_table_scan_postgres	12.62/s	12.43/s	-1.6%

[itoqa]

Commit: 97fe0ac: 10 test cases ran, 9 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans core server startup and configuration, database identity and persistence across restarts, schema and type handling, versioned data changes, dependency and build tooling, and recovery from storage write failures. The exercised behavior is predominantly happy-path product and data flows, with edge-case coverage for restart persistence, invalid operations, dependency prerequisites, and retryable storage failures.

Safe to merge — the sole observed failure is a pre-existing medium-severity restart-related panic affecting persisted user-defined enum arrays and is explicitly unrelated to this PR; no regression or PR-attributable failure was found.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Bootstrap	A fresh local Doltgres data directory booted successfully, accepted the default postgres connection, and created, inserted, and queried a table with the expected row.
✅	—	Bootstrap	Two disposable repositories were initialized with distinct marker rows and credentials. Starting and restarting Doltgres with the custom-a data directory authenticated qauser, selected the postgres database, returned marker id 1, excluded custom-b's marker, and reported a ready listener.
✅	—	Build	The updated Dolt module resolved and the complete linux-amd64 Doltgres server build completed successfully in the documented Go 1.26 Docker build environment. The resulting executable artifact was verified; the repository wrapper could not run inside the nested container only because Docker is unavailable there.
✅	—	Build	The initial clean and warm runs reported failures because the isolated Go environment lacked ICU headers, PostgreSQL tooling and extension files, and the timezone expected by wire fixtures. After those prerequisites were provisioned and America/Los_Angeles was configured, the targeted extension, backup, remote, and wire consumers passed against the selected Dolt revision.
✅	—	Schema	Enum, domain, composite, scalar, and array values were created, queried, and round-tripped successfully. Catalog metadata and expression typing matched the expected PostgreSQL identities, including nullable values and array concatenation.
✅	—	Storage	The README example schema reopened successfully after restarting Doltgres with the same disposable data directory. All committed rows, three table definitions, and the Dolt commit metadata remained intact.
✅	—	Storage	Controlled NodeStore write failures returned errors without replacing the existing sequence or type collection map, and both collections remained usable after writes were restored. The earlier filesystem and browser attempts were limited by the local test environment, so the recovery contract was verified with focused in-process failure tests instead.
✅	—	Tooling	The minimum-version generator compiled and ran with the updated Dolt dependency, producing the expected non-empty validation file. The initial .go output-path attempt exposed Go 1.26 go-run argument parsing, so the output was generated without the suffix and renamed afterward; this did not indicate a defect in the repository utility.
✅	—	Version	Employee and team changes moved from unstaged to staged, were committed successfully, and remained visible from a separate connection with a clean status and the new commit at HEAD.
⚠️		Schema	Before restart, enum, domain, array catalog identities, valid casts, and the controlled invalid cast behaved as expected. After restart, selecting the persisted priority[] value produced a nil-pointer panic through CallReceive, DeserializeValue, deserializeArray, and deserializeTypeArray instead of returning the array value.

Additional Findings Details

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

🟡 Persisted array reads panic after restart

• Severity: Medium
• Description: Before restart, enum, domain, array catalog identities, valid casts, and the controlled invalid cast behaved as expected. After restart, selecting the persisted priority[] value produced a nil-pointer panic through CallReceive, DeserializeValue, deserializeArray, and deserializeTypeArray instead of returning the array value.
• Impact: After a restart, users who query persisted user-defined enum arrays can encounter a server panic instead of receiving the array value. Scalar enum and domain values remain usable, and the evidence does not show data loss or corruption.
• Steps to Reproduce:
  1. Create a user-defined enum and a table containing an array of that enum, then insert an array value.
  2. Restart the local Doltgres server and open a fresh session.
  3. Select the persisted array value and observe the nil-pointer panic; scalar enum and domain reads still succeed.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The production path is direct: server/doltgres_handler.go:332 calls dgType.CallReceive for binary values; server/types/type.go:1197 dereferences t.Elem.ID for array or mod-in types without checking whether t.Elem is nil; server/types/array.go:93 calls t.ArrayBaseType(), whose server/types/type.go:167 implementation also dereferences t.Elem. server/types/serialization.go:152-164 reconstructs Elem and Array during persisted type deserialization, so a missing element linkage after restart reaches these unchecked dereferences. The smallest practical fix is to validate the element linkage before dereferencing it and return a normal type/deserialization error or resolve the missing element type, rather than panicking.

Evidence Package

• text/SCHEMA-2/SCHEMA-2-persisted-array-panic.txt — 3 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18320	18321
Failures	23770	23769
Partial Successes1	5276	5276

	Main	PR
Successful	43.5258%	43.5282%
Failures	56.4742%	56.4718%

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

random

QUERY: (SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1);

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