[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	1801.98/s	1709.37/s	-5.2%
groupby_scan_postgres	121.19/s	123.86/s	+2.2%
index_join_postgres	627.17/s	616.76/s	-1.7%
index_join_scan_postgres	765.07/s	778.61/s	+1.7%
index_scan_postgres	23.66/s	24.35/s	+2.9%
oltp_delete_insert_postgres	747.94/s	724.78/s	-3.1%
oltp_insert	701.51/s	${\color{red}540.14/s}$	${\color{red}-23.1\%}$
oltp_point_select	2765.22/s	2783.07/s	+0.6%
oltp_read_only	2824.01/s	2804.79/s	-0.7%
oltp_read_write	2337.84/s	${\color{red}1949.58/s}$	${\color{red}-16.7\%}$
oltp_update_index	735.02/s	${\color{red}642.22/s}$	${\color{red}-12.7\%}$
oltp_update_non_index	753.87/s	679.61/s	-9.9%
oltp_write_only	1706.40/s	${\color{red}1469.48/s}$	${\color{red}-13.9\%}$
select_random_points	1748.57/s	1727.11/s	-1.3%
select_random_ranges	1047.66/s	1050.71/s	+0.2%
table_scan_postgres	22.04/s	22.77/s	+3.3%
types_delete_insert_postgres	764.41/s	743.66/s	-2.8%
types_table_scan_postgres	7.59/s	7.69/s	+1.3%

[itoqa]

Commit: f4c3ef4: 5 test cases ran, 1 failed ❌, 4 passed ✅, 0 additional findings ⚠️.

Summary

This run covered core database behavior across normal operations and resilience paths, including schema updates, startup input handling, and restart/recovery behavior under misconfiguration. Most exercised areas behaved correctly, but there is a functional regression in schema-change behavior that affects migration-like workflows.

Merge with caution — the results indicate a medium-severity bug introduced by this PR in a data-definition path, while other key behaviors remained stable. Because it can break real schema evolution flows, this is meaningful release risk even though the rest of the covered surface looks healthy.

Tests run by Ito

Result	Severity	Type	Description
❌		Storage	Renaming a table with an existing FK fails with "foreign key ... was not found" even though the FK is present immediately before the rename.
✅	—	Planner	ALTER TABLE employees ADD COLUMN title text succeeded, information_schema exposed the new column, and subsequent INSERT/SELECT operations using the new column completed without planner or hook errors.
✅	—	Server	With a fresh data directory, the server auto-created the default postgres database, allowed creating and inserting into bootstrap_check, and preserved that table and row after restart.
✅	—	Server	With an intentionally unreachable replication endpoint, the listener still came up and remained usable, and restarting with corrected configuration did not leave corrupted startup state.
✅	—	Session	A crafted database startup parameter containing SQL syntax was rejected as an invalid catalog name, and the guard table remained readable and writable after the attempt.

Tip

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

[itoqa]

Rename fails on foreign key tables

What failed: Renaming a table with an existing FK fails with "foreign key ... was not found" even though the FK is present immediately before the rename.

Impact · Steps · Stub / mock · Analysis · Why this is likely a bug

• Severity: Medium
• Impact: Users cannot rename tables that have foreign key constraints, so schema migrations that depend on table renames can fail and block releases.
• Steps to Reproduce:
  1. Create parent_t and child_t with a foreign key from child_t.parent_id to parent_t.id.
  2. Confirm the FK exists in pg_constraint, then run ALTER TABLE child_t RENAME TO child_t_renamed.
  3. Observe errno 1105 foreign-key-not-found; repeat with a table without FKs and observe rename succeeds.
• Stub / mock content: Authentication was intentionally bypassed in the local QA environment to allow direct test connections, but no stubs or mocked database responses were used for the rename behavior itself.
• Code Analysis: The runner reproduced this deterministically in a single-client session and captured code-level evidence that the updated dependency path mutates FK table naming before lookup, producing a name mismatch and ErrForeignKeyNotFound. This PR's changed go.mod dependency lines are the direct changed-code causal path: they move dolt/go and go-mysql-server to versions where the rename/FK interaction fails for FK-bearing tables. In this repo, RootValue.RenameTable also updates table/sequence metadata but does not update foreign-key collection entries, which is consistent with the observed stale-name lookup behavior. The smallest practical fix is to make rename and FK metadata updates consistent in the renamed dependency path (or pin/revert to a known-good dependency version while applying that targeted correction).
• Why this is likely a bug: This is a production-code defect, not test setup noise: it reproduces without concurrency, fails only when an FK exists, and succeeds on a no-FK control case. The observed behavior contradicts expected DDL semantics because a valid FK present in catalog metadata should not block a rename as "not found".

Relevant code

go.mod:9-12

github.com/dolthub/dolt/go v0.40.5-0.20260625164551-d286e8926c62
github.com/dolthub/go-mysql-server v0.20.1-0.20260624214512-1199bbe99f4e

core/rootvalue.go:800-817

newStorage, err := root.st.EditTablesMap(ctx, root.vrw, root.ns, []storage.TableEdit{{OldName: oldName, Name: newName}})
if err != nil {
	return nil, err
}
newRoot := root.withStorage(newStorage)

collection, err := sequences.LoadSequences(ctx, newRoot)
if err != nil {
	return nil, err
}
seqs, err := collection.GetSequencesWithTable(ctx, oldName)
if err != nil {
	return nil, err
}
for _, seq := range seqs {
	seq.OwnerTable = id.NewTable(seq.OwnerTable.SchemaName(), newName.Name)
}
return collection.UpdateRoot(ctx, newRoot)

Evidence Package

• text/STORAGE-1/STORAGE-1-fk-rename-repro.txt — 2 KB

Copy prompt for an agent

Ito QA identified the following failure during automated PR testing. Please investigate and propose a fix.

**Medium severity — Rename fails on foreign key tables**

**What failed:** Renaming a table with an existing FK fails with "foreign key ... was not found" even though the FK is present immediately before the rename.

- **Impact:** Users cannot rename tables that have foreign key constraints, so schema migrations that depend on table renames can fail and block releases.
- **Steps to reproduce:**
  1. Create parent_t and child_t with a foreign key from child_t.parent_id to parent_t.id.
  2. Confirm the FK exists in pg_constraint, then run ALTER TABLE child_t RENAME TO child_t_renamed.
  3. Observe errno 1105 foreign-key-not-found; repeat with a table without FKs and observe rename succeeds.
- **Stub / mock content:** Authentication was intentionally bypassed in the local QA environment to allow direct test connections, but no stubs or mocked database responses were used for the rename behavior itself.
- **Code analysis:** The runner reproduced this deterministically in a single-client session and captured code-level evidence that the updated dependency path mutates FK table naming before lookup, producing a name mismatch and ErrForeignKeyNotFound. This PR's changed go.mod dependency lines are the direct changed-code causal path: they move dolt/go and go-mysql-server to versions where the rename/FK interaction fails for FK-bearing tables. In this repo, RootValue.RenameTable also updates table/sequence metadata but does not update foreign-key collection entries, which is consistent with the observed stale-name lookup behavior. The smallest practical fix is to make rename and FK metadata updates consistent in the renamed dependency path (or pin/revert to a known-good dependency version while applying that targeted correction).
- **Why this is likely a bug:** This is a production-code defect, not test setup noise: it reproduces without concurrency, fails only when an FK exists, and succeeds on a no-FK control case. The observed behavior contradicts expected DDL semantics because a valid FK present in catalog metadata should not block a rename as "not found".

**Relevant code:**

`go.mod:9-12`

~~~go
github.com/dolthub/dolt/go v0.40.5-0.20260625164551-d286e8926c62
github.com/dolthub/go-mysql-server v0.20.1-0.20260624214512-1199bbe99f4e
~~~

`core/rootvalue.go:800-817`

~~~go
newStorage, err := root.st.EditTablesMap(ctx, root.vrw, root.ns, []storage.TableEdit{{OldName: oldName, Name: newName}})
if err != nil {
	return nil, err
}
newRoot := root.withStorage(newStorage)

collection, err := sequences.LoadSequences(ctx, newRoot)
if err != nil {
	return nil, err
}
seqs, err := collection.GetSequencesWithTable(ctx, oldName)
if err != nil {
	return nil, err
}
for _, seq := range seqs {
	seq.OwnerTable = id.NewTable(seq.OwnerTable.SchemaName(), newName.Name)
}
return collection.UpdateRoot(ctx, newRoot)
~~~

[github-actions]

	Main	PR
Total	42090	42090
Successful	18270	18270
Failures	23820	23820
Partial Successes1	5334	5334

	Main	PR
Successful	43.4070%	43.4070%
Failures	56.5930%	56.5930%

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 #2873