[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
Total	42090	42090
Successful	18407	18407
Failures	23683	23683
Partial Successes1	5327	5327

	Main	PR
Successful	43.7325%	43.7325%
Failures	56.2675%	56.2675%

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]

	Main	PR
covering_index_scan_postgres	2226.72/s	2162.66/s	-2.9%
groupby_scan_postgres	147.69/s	152.30/s	+3.1%
index_join_postgres	693.15/s	703.56/s	+1.5%
index_join_scan_postgres	915.18/s	914.73/s	-0.1%
index_scan_postgres	32.99/s	32.54/s	-1.4%
oltp_delete_insert_postgres	893.73/s	869.35/s	-2.8%
oltp_insert	801.10/s	766.72/s	-4.3%
oltp_point_select	3825.71/s	3843.93/s	+0.4%
oltp_read_only	3639.33/s	3655.46/s	+0.4%
oltp_read_write	2668.57/s	2622.83/s	-1.8%
oltp_update_index	832.25/s	822.59/s	-1.2%
oltp_update_non_index	880.90/s	883.02/s	+0.2%
oltp_write_only	1850.75/s	1884.21/s	+1.8%
select_random_points	2209.28/s	2206.40/s	-0.2%
select_random_ranges	1647.04/s	1680.36/s	+2.0%
table_scan_postgres	32.61/s	32.48/s	-0.4%
types_delete_insert_postgres	873.30/s	888.69/s	+1.7%
types_table_scan_postgres	14.30/s	14.72/s	+2.9%

[itoqa]

Commit: 0150a12: 12 test cases ran, 6 passed ✅, 6 additional findings ⚠️.

Summary

Coverage spans core database behavior: normal data and schema operations, persistence across reconnects and branch merges, prepared-query handling, startup validation, sequence allocation, and PostgreSQL compatibility. It also exercises edge cases such as invalid configuration, concurrent sequence use, restart behavior, divergent branches, cyclic sequences, and recovery after query errors.

Safe to merge — none of the observed failures are attributable to this dependency-only PR, so there is no identified regression or merge blocker. The run does surface several pre-existing medium- and high-severity database defects, including rename failures, sequence readback gaps, and merge crashes, which are important follow-up issues but do not increase the risk of this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Sequence	Permanent sequences are supported, while temporary and unlogged sequences return clear unsupported-feature errors by design. The failed check was caused by asking the product to support persistence modes that are not implemented, so no application bug was confirmed.
✅	—	Sql	Prepared queries with nested filters, casts, repeated values, limits, and offsets ran successfully and returned the expected results.
✅	—	Sql	Prepared queries returned the expected bind error for incompatible values, then the same connection completed the remaining prepared-query checks successfully.
✅	—	Startup	Missing, malformed, and unknown configuration files all stopped the server and showed a useful error. The server did not start with partial settings.
✅	—	Storage	After the database was reloaded, the merged schema still had its table, both key rules, and exactly the two expected rows.
✅	—	Storage	After the branch merge and a fresh database connection, the table, generated IDs, sequences, functions, and procedure were all still available and usable.
⚠️		Sequence	The divergent allocations and both commits succeeded, but merging the feature branch crashed with a nil-pointer error in the database merge path. The expected result was a completed merge that kept the greatest compatible sequence progress and allowed a fresh session to allocate the next value.
⚠️		Startup	The server starts, but renaming a table fails instead of completing. The failure is not cleared by opening a warmed connection or restarting the server.
⚠️		Sequence	The concurrent inserts completed and produced 20 unique IDs, but the current-value query returned an error saying that the currval function was not found.
⚠️		Startup	The server accepted the schema and table creation, then returned table not found: initial_table when the table was renamed. The expected result was a successful rename followed by the column changes and final metadata checks.
⚠️		Storage	After the database was reloaded, the main branch returned 37 and the feature branch returned 38 instead of following their committed sequence values. The standard current-value call failed with a function-not-found error, and switching back to main ended with a multi-branch commit error.
⚠️		Storage	The sequence wrapped in the right direction after reopening, but merging the branch crashed the database instead of preserving the sequence and completing the merge.

Additional Findings Details

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

🟠 Branch merge crashes during sequence updates

• Severity: High
• Description: The divergent allocations and both commits succeeded, but merging the feature branch crashed with a nil-pointer error in the database merge path. The expected result was a completed merge that kept the greatest compatible sequence progress and allowed a fresh session to allocate the next value.
• Impact: Users cannot complete a branch merge after both branches allocate sequence values. The database crashes instead of finishing the merge, so the branch workflow is blocked.
• Steps to Reproduce:
  1. Create a sequence and commit the initial state on the main branch.
  2. Create a feature branch, allocate two sequence values, and commit the feature branch.
  3. Switch back to main, allocate two more sequence values, and commit the main branch.
  4. Run the branch merge from the main branch.
  5. Observe that the merge returns a nil-pointer panic instead of completing; post-merge sequence allocation cannot be performed.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The recorded stack trace identifies github.com/dolthub/dolt/go/libraries/doltcore/sqle/dprocedures.applyChanges as the caller of core.RootValue.SetTableHash during dolt_merge. In /tmp/output-agent-workspace/repo/core/rootvalue.go:899-911, SetTableHash reads the table value with root.vrw.ReadValue(ctx, h), then immediately passes val to types.NewRef at line 906. The panic shows types.NewRef received a zero or nil value ({0x0, 0x0}) and dereferenced it in the Dolt dependency. Because the error occurs inside the merge operation while applying a table hash, the application exposes an unhandled invalid value instead of returning a controlled merge error or preserving the compatible sequence state. The smallest practical fix is to validate the value returned by ReadValue before calling types.NewRef and return a descriptive error for an absent or invalid table value; the merge path should then handle that error without panicking. The PR context changes only the Dolt and go-mysql-server dependency versions in go.mod and go.sum, with no changed application lines in this path, so PR causation cannot be established from the supplied diff.

Evidence Package

• text/SEQUENCE-3/SEQUENCE-3-merge-panic.txt — 3 KB

🟠 Restarted servers fail table rename operations

• Severity: High
• Description: The server starts, but renaming a table fails instead of completing. The failure is not cleared by opening a warmed connection or restarting the server.
• Impact: Users cannot rename tables through the supported PostgreSQL workflow. This blocks an important database operation, and avoiding table renames is not a practical workaround for users who need them.
• Steps to Reproduce:
  1. Start a local server with the default PostgreSQL configuration.
  2. Create a schema and table, then run an ALTER TABLE ... RENAME TO statement.
  3. Repeat the operation using a warmed connection and after restarting the server.
  4. Observe that the rename fails with a table-not-found error before the rename workflow completes.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: server/server.go:90-112 calls initialization.Initialize(dEnv, cfg) on every server process startup, then converts the configuration and applies the SQL server settings. servercfg/config.go:42-72 returns the PostgreSQL parser, schema formatter, planner filter, and DDL hooks; in particular, the RenameTable post-execution hook is always set to hook.AfterTableRename at lines 49-52. In server/hook/rename_table.go:39-43, AfterTableRename resolves the post-rename table with n.NewNames[0]. It then converts that table to a Dolt table at lines 45-48, but at lines 54-56 replaces the resolved table name with n.OldNames[0] before constructing the root table type identifier. The subsequent root scan at lines 57-87 therefore searches using an old-name-derived identifier after the table has already been renamed. This is consistent with the recorded table-not-found error and leaves the rename lifecycle incomplete. The smallest practical fix is to keep the post-rename name when constructing tableAsType, or otherwise resolve the root metadata using one consistently valid name after the rename; the hook should still use n.NewNames[0] when generating the dependent-column ALTER statements at lines 90-91.

Evidence Package

• text/STARTUP-3/STARTUP-3-rename-lifecycle.txt — 4 KB

🟡 Current sequence value cannot be read

• Severity: Medium
• Description: The concurrent inserts completed and produced 20 unique IDs, but the current-value query returned an error saying that the currval function was not found.
• Impact: Applications that use the standard PostgreSQL currval function cannot read the current sequence value after an insert because the query fails. Sequence allocation itself still produces unique IDs, so this affects sequence readback rather than the stored rows.
• Steps to Reproduce:
  1. Connect to a local Doltgres database and create a table with a SERIAL primary key.
  2. Run four PostgreSQL sessions concurrently, inserting five rows from each session.
  3. Query the table and confirm that 20 rows have 20 distinct IDs ranging from 1 through 20.
  4. Run SELECT currval('public.concurrent_ids_batch2_id_seq') to read the sequence's current value.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime output confirms that SERIAL allocation and concurrent sequence advancement work for this case: the table contains 20 rows, all IDs are distinct, and the range is 1 through 20. The failure is a separate PostgreSQL compatibility defect in the required readback operation. core/id/cache_function_defaults.go:956-957 advertises both nextval and currval in the built-in function catalog, and server/analyzer/optimize_functions.go:55-56 and :100-101 treats currval as a sequence function, but the server/functions package contains setval.go and no currval implementation or registration. This leaves the advertised currval name unresolved at execution time, producing the observed 'function: currval not found' error. The smallest practical fix is to add and register the supported currval(text/regclass) overload, resolve the sequence in the current database, and return the current session's last value with the standard error when that session has not called nextval. The dependency-only PR diff changes only go.mod and go.sum, so none of these application lines were introduced or modified by the PR.

Evidence Package

• text/SEQUENCE-2/SEQUENCE-2-concurrency-readback.txt — 2 KB

🟡 Table rename stops DDL changes

• Severity: Medium
• Description: The server accepted the schema and table creation, then returned table not found: initial_table when the table was renamed. The expected result was a successful rename followed by the column changes and final metadata checks.
• Impact: Users who rename database tables through the default PostgreSQL path receive an error, and the table keeps its old name. Follow-up schema changes in that workflow cannot complete.
• Steps to Reproduce:
  1. Start a fresh local Doltgres server with the default configuration.
  2. Connect to a database and run CREATE SCHEMA startup_ddl_test;.
  3. Run CREATE TABLE startup_ddl_test.initial_table (id bigint PRIMARY KEY, legacy_name text);.
  4. Run ALTER TABLE startup_ddl_test.initial_table RENAME TO renamed_table;.
  5. Check the schema metadata after the error. The old table name is still present and the new name is absent.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The default configuration in servercfg/config.go:43-72 installs the PostgreSQL parser and registers hook.AfterTableRename as the post-execution RenameTable hook at lines 49-52, so this behavior is part of the normal server path rather than an optional test configuration. server/ast/rename_table.go:44-48 converts PostgreSQL RENAME TABLE into the generic Vitess RenameTable plan with the original name in FromTables and the new name in ToTables. In server/hook/rename_table.go:39-45, AfterTableRename correctly looks up the already-renamed SQL table with n.NewNames[0]. However, lines 54-57 then overwrite the table identifier with n.OldNames[0] before calling root.GetAllTableNames. That mixes the post-rename table object with an old-name root identifier. The hook subsequently compares table-type IDs and issues follow-up ALTER statements using the new name at lines 85-91, but it can fail first while enumerating the root state. The smallest practical fix is to keep the table identifier based on the post-rename name when building tableAsType, or otherwise use the root lookup identifier that matches the renamed table; then add a regression test covering a default-configured ALTER TABLE ... RENAME TO.

Evidence Package

• text/STARTUP-1/STARTUP-1-ddl-rename-failure.txt — 3 KB

🟡 Sequence current value is unavailable after branch reload

• Severity: Medium
• Description: After the database was reloaded, the main branch returned 37 and the feature branch returned 38 instead of following their committed sequence values. The standard current-value call failed with a function-not-found error, and switching back to main ended with a multi-branch commit error.
• Impact: Clients that use the standard currval function cannot read the current sequence value after generating an ID. They receive an error instead of the value, so workflows that depend on that read cannot complete normally.
• Steps to Reproduce:
  1. Create a sequence and commit it at different values on main and s2_feature.
  2. Leave the sequence session state in place, reload the database, and call nextval on main and then s2_feature from fresh connections.
  3. Call currval for the sequence and then switch back to main.
  4. Observe the unexpected allocations, the missing currval function, and the branch-switch error.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The currval failure is a production-code defect: core/id/cache_function_defaults.go assigns a catalog identifier to currval, and the analyzer recognizes currval for authorization, but server/functions/nextval.go:initNextVal registers only the two nextval overloads. No currval callable is defined in server/functions, and core/sequences/collection.go exposes NextVal and SetVal but no session-scoped current-value operation. A normal PostgreSQL client therefore reaches function resolution and receives function: 'currval' not found, matching the captured readback. The branch result is a separate state-model problem or limitation rather than evidence that the PR changed branch semantics: nextval obtains its state from the shared dsess.SequenceTracker and then updates the database collection, while the repository's own sequence test documents global tracking across checkout. The later multi-branch commit error is consistent with the session retaining dirty sequence state while branch operations change the working root; core/context.go:updateSessionRootForDatabase at lines 463-517 writes cached collections back through SetWorkingRoot and explicitly notes that Dolt permits only one dirty working set per commit. The smallest practical fix for the confirmed API defect is to register and implement currval using the tracker state for the current session, returning PostgreSQL's clear "currval of sequence ... is not yet defined in this session" error when no nextval or setval has occurred. Separately, branch-local sequence semantics would require an explicit product decision and targeted tracker invalidation or refresh on checkout; the current source and existing test indicate that behavior is not introduced by this PR.

Evidence Package

• text/STORAGE-2/STORAGE-2-sequence-readback.txt — 3 KB

🟡 Branch merge crashes after sequence restart

• Severity: Medium
• Description: The sequence wrapped in the right direction after reopening, but merging the branch crashed the database instead of preserving the sequence and completing the merge.
• Impact: Merging a branch can crash the database when it contains this sequence after a restart. The merge does not complete, so the sequence changes are not preserved until the issue is fixed.
• Steps to Reproduce:
  1. Create a cyclic sequence with start -1, increment -2, minimum -5, maximum 1, and cycle enabled.
  2. Call nextval enough times to observe -1, -3, -5, 1, and -1, then commit the state.
  3. Reopen the database and call nextval again; observe -3, -5, and 1 with the same sequence metadata.
  4. Create and commit a mutation on another branch, switch back, and run the branch merge.
  5. Observe that the merge returns a nil-pointer panic instead of completing.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The recorded server stack traces the failure from the Dolt merge procedure's applyChanges call into github.com/dolthub/doltgresql/core.(*RootValue).SetTableHash at core/rootvalue.go:906. SetTableHash reads the supplied hash with root.vrw.ReadValue(ctx, h), then immediately passes the returned val to types.NewRef at lines 901-907. The panic occurs inside types.NewRef because the value passed to it is nil, so this production path does not convert the merge result into a valid table reference or return an error. The resulting failure is a server panic during dolt_merge, not a browser or test-runner problem. The sequence-specific merge implementation in core/sequences/collection_funcs.go:40-114 merges the sequence objects and reports a modified root object; the root-level application of the resulting changes then reaches SetTableHash. A targeted fix should validate the value returned by ReadValue before NewRef and return a descriptive error, while preserving the normal valid-hash path; the merge caller should then handle that error without taking down the server.

Evidence Package

• text/STORAGE-4/STORAGE-4-merge-panic.txt — 5 KB

Tip

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

[github-actions]

This PR has been superseded by #3084