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

[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	1791.09/s	1764.64/s	-1.5%
groupby_scan_postgres	131.83/s	131.89/s	0.0%
index_join_postgres	638.02/s	636.72/s	-0.3%
index_join_scan_postgres	780.40/s	775.01/s	-0.7%
index_scan_postgres	23.90/s	24.11/s	+0.8%
oltp_delete_insert_postgres	803.98/s	766.81/s	-4.7%
oltp_insert	684.24/s	664.85/s	-2.9%
oltp_point_select	2806.35/s	2804.97/s	-0.1%
oltp_read_only	2785.49/s	2817.97/s	+1.1%
oltp_read_write	2178.07/s	2218.75/s	+1.8%
oltp_update_index	699.85/s	714.97/s	+2.1%
oltp_update_non_index	750.19/s	747.51/s	-0.4%
oltp_write_only	1655.98/s	1609.93/s	-2.8%
select_random_points	1765.10/s	1766.91/s	+0.1%
select_random_ranges	1049.18/s	1041.62/s	-0.8%
table_scan_postgres	22.58/s	22.63/s	+0.2%
types_delete_insert_postgres	745.99/s	711.89/s	-4.6%
types_table_scan_postgres	7.83/s	7.78/s	-0.7%

[itoqa]

Commit: 324be76: 10 test cases ran, 0 failed ❌, 7 passed ✅, 3 additional findings ⚠️.

Summary

Coverage spans core database server behavior, including first-boot initialization and recovery, connection startup and query readiness, restart persistence, concurrent schema-change handling, and authorization validation messaging. Overall health appears strong on primary startup and normal SQL paths, with concerns concentrated in edge-case robustness and correctness scenarios.

Safe to merge — the failures observed are marked as pre-existing and not introduced by this PR, while the main startup, connectivity, and standard query flows remained stable. The remaining issues are confined to known edge-case reliability and messaging consistency areas, making them follow-up items rather than blockers for this merge.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Authorization	Connected to doltgres on port 5432 as default superuser (postgres) and successfully executed SELECT, CREATE TABLE, INSERT, CREATE INDEX, CREATE VIEW, view query, and aggregate statements through the PostgreSQL wire-protocol path.
✅	—	Catalog	Table catalog_insert_test remained queryable with the same rows after restart, confirming CREATE TABLE catalog mappings were serialized and replayed correctly.
✅	—	Session	A raw PostgreSQL StartupMessage with user/database set to postgres completed AuthenticationOk, reached ReadyForQuery, and a follow-up SELECT 1 returned the expected row before a second ReadyForQuery.
✅	—	Session	A startup message without a database parameter correctly fell back to the username, suppressed the missing-database fallback error from the client, reached ReadyForQuery, and successfully executed SELECT 1.
✅	—	Startup	First boot with an empty data directory and DOLTGRES_DB=postgres successfully created the default postgres database, served metrics on :9187, and accepted psql queries on :5432.
✅	—	Startup	Startup correctly aborts with an explicit slot_name validation error and then exits cleanly without leaving a listener on 5432 or 9187.
✅	—	Startup	A forced default-database creation error shut the process down cleanly with no ghost listeners or partial database artifacts, and a retry in the same data directory started normally with healthy SQL and metrics responses.
⚠️		Catalog	The expected result is one coherent outcome with deterministic conflict handling for concurrent DDL on the same table. Instead, runs showed both commands succeeding while the renamed table remained present and writable.
⚠️		Session	Expected behavior is iterative handling of negotiation requests with bounded control flow; actual behavior recursively calls handleStartup() for each SSL/GSS negotiation frame, leaving depth unbounded for repeated client input.
⚠️	—	Authorization	For SequenceIdentifiers with invalid arity, the handler should report a sequence-specific unsupported-count error, but it currently returns "function identifiers has an unsupported count".

Additional Findings Details

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

🟠 Concurrent rename and drop leave orphaned table mapping

• Severity: High
• Description: The expected result is one coherent outcome with deterministic conflict handling for concurrent DDL on the same table. Instead, runs showed both commands succeeding while the renamed table remained present and writable.
• Impact: Concurrent rename and drop operations can leave orphaned table mappings in the catalog while both commands report success. This can cause incorrect table lifecycle behavior and persistent metadata inconsistency that requires manual repair.
• Steps to Reproduce:
  1. Create a table such as catalog_concurrent_test in one database session.
  2. Run ALTER TABLE ... RENAME TO ... and DROP TABLE <old_name> concurrently in separate sessions and commit both transactions.
  3. Repeat the race and inspect final relations; some runs leave only the renamed table even though DROP reported success for the old name.
• Stub / mock content: The run disabled authentication in the local test environment to allow scripted SQL sessions, and no catalog operation stubs or mocks were applied.
• Code Analysis: core/rootvalue.go routes both operations through storage.EditTablesMap: RenameTable calls EditTablesMap with an OldName->Name rename edit, while RemoveTables calls EditTablesMap with delete edits. In core/storage/storage.go, EditTablesMap applies these name-keyed map edits from each transaction snapshot and the delete branch performs ae.Delete without validating that the target still refers to the same table identity at commit. A minimal practical fix is to add commit-time revalidation/compare-and-swap semantics for DROP/rename table-map edits so a DROP on an old name fails with a conflict/table-not-found when a concurrent rename has already moved the mapping.

Evidence Package

• text/CATALOG-2/CATALOG-2-concurrent-rename-drop-evidence.txt — 3 KB

🟠 Unbounded startup recursion on repeated negotiation requests

• Severity: High
• Description: Expected behavior is iterative handling of negotiation requests with bounded control flow; actual behavior recursively calls handleStartup() for each SSL/GSS negotiation frame, leaving depth unbounded for repeated client input.
• Impact: A client can drive repeated pre-auth startup recursion and potentially exhaust server resources, causing connection handling instability or denial of service. The issue is reachable before normal session initialization and has no built-in recursion cap.
• Steps to Reproduce:
  1. Open a TCP connection to the PostgreSQL listener.
  2. Send SSLRequest or GSSEncRequest frames repeatedly without sending a StartupMessage.
  3. Observe that each request path calls the startup handler again, increasing recursive call depth.
  4. Continue until resource pressure appears, then verify connection handling degrades or fails.
• Stub / mock content: Authentication was intentionally disabled in this QA run to allow raw wire-protocol startup checks without SCRAM credential setup; no request/response mocking or route interception was applied.
• Code Analysis: In server/connection_handler.go, the SSLRequest and GSSEncRequest switch branches both return h.handleStartup() after writing 'N'/'S'. That creates one additional stack frame per negotiation message, so repeated requests before StartupMessage can grow recursion depth without a guard or loop-based bound.

Evidence Package

• text/SESSION-3/SESSION-3-negotiation-recursion-evidence.txt — 3 KB

Sequence auth error message is mislabeled

• Description: For SequenceIdentifiers with invalid arity, the handler should report a sequence-specific unsupported-count error, but it currently returns "function identifiers has an unsupported count".
• Impact: Authorization enforcement still denies malformed sequence requests, but troubleshooting output is inaccurate for this path.
• Steps to Reproduce:
  1. Build and run the local authz test program that calls AuthorizationHandler.HandleAuth with TargetType set to SequenceIdentifiers and an odd-length TargetNames vector.
  2. Observe the returned error text for that case.
  3. Compare the SequenceIdentifiers branch in server/auth/auth_handler.go with the FunctionIdentifiers branch and confirm the sequence guard returns a copied "function identifiers" message.
• Stub / mock content: The run used a local authentication bypass (SCRAM disabled) to reach authorization code paths without login-gating; this setup does not change the SequenceIdentifiers error-string branch that was exercised.
• Code Analysis: Inspected server/auth/auth_handler.go: the SequenceIdentifiers validation at lines 197-200 checks the right modulo condition but returns the wrong label string. Runtime evidence from AUTHORIZATION-2 case 4 reproduces the same mislabeled output. A targeted fix is to change that one error string to "sequence identifiers has an unsupported count: %d".

Evidence Package

• text/AUTHORIZATION-2/AUTHORIZATION-2-sequence-identifiers-error-mismatch.txt — 2 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18269	18271
Failures	23821	23819
Partial Successes1	5334	5334

	Main	PR
Successful	43.4046%	43.4094%
Failures	56.5954%	56.5906%

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

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);

subselect

QUERY: select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);

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