[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	1919.56/s	1948.68/s	+1.5%
groupby_scan_postgres	122.59/s	128.82/s	+5.0%
index_join_postgres	669.34/s	667.39/s	-0.3%
index_join_scan_postgres	856.06/s	848.11/s	-1.0%
index_scan_postgres	25.06/s	25.03/s	-0.2%
oltp_delete_insert_postgres	829.17/s	832.85/s	+0.4%
oltp_insert	715.05/s	733.41/s	+2.5%
oltp_point_select	3061.86/s	3053.00/s	-0.3%
oltp_read_only	3023.66/s	3033.94/s	+0.3%
oltp_read_write	2304.81/s	2326.27/s	+0.9%
oltp_update_index	739.30/s	749.20/s	+1.3%
oltp_update_non_index	797.75/s	786.10/s	-1.5%
oltp_write_only	1769.29/s	1745.68/s	-1.4%
select_random_points	1939.42/s	1932.36/s	-0.4%
select_random_ranges	1135.10/s	1137.93/s	+0.2%
table_scan_postgres	24.20/s	24.36/s	+0.6%
types_delete_insert_postgres	790.93/s	772.39/s	-2.4%
types_table_scan_postgres	8.56/s	8.62/s	+0.7%

[itoqa]

Commit: 47bf1d6: 13 test cases ran, 0 failed ❌, 8 passed ✅, 5 additional findings ⚠️.

Summary

This run exercised core database behavior across normal query execution, data modification, startup and replication initialization, and prepared-statement protocol handling, including both expected flows and malformed or abuse-style inputs. Overall product behavior is mostly stable in routine paths, while known gaps remain in some startup robustness, protocol strictness, and security-sensitive edge cases.

Safe to merge — the observed failures are flagged as pre-existing and not introduced by this PR, while the covered baseline flows continue to behave as expected. There are still high-impact issues in older edge and hardening paths, but they read as backlog risk rather than a new regression from this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Prepared	Raw protocol execution returned ParseComplete, BindComplete, DataRow, CommandComplete, and clean CloseComplete messages in order for the bound employee lookup.
✅	—	Prepared	Prepared statements executed successfully with both empty and mixed explicit-plus-zero parameter OID lists, returning the expected employee rows without bind type errors.
✅	—	Prepared	The remediation run confirms correct behavior: after a deterministic invalid int8 bind, the server returns ErrorResponse and ReadyForQuery before accepting the next successful Parse/Bind/Execute cycle.
✅	—	Query	The SELECT query returned three ordered employee rows and completed normally without protocol errors.
✅	—	Query	INSERT into a temporary table completed with the expected command tag and rows-affected count of 2.
✅	—	Query	A three-statement query executed sequentially: the first statement committed, the second failed as expected on a missing table, and the third statement was skipped.
✅	—	Query	The mixed workload kept command tags, affected-row counts, row streaming, and returned field metadata consistent after the dependency bump.
✅	—	Startup	Replication required-field validation behaved as expected: startup exited non-zero with an explicit missing slot_name error. Subsequent rerun attempts were blocked by local container/runtime availability, but the captured run and source path confirm the intended validation behavior.
⚠️		Prepared	Expected behavior is a Bind-time rejection for mismatched format-code list length, but the server accepts the payload and executes the statement.
⚠️		Query	Unsafe absolute file paths were accepted and ingested by COPY FROM instead of being constrained or rejected.
⚠️		Startup	Startup does not enforce a single initializer for first-boot default database creation, so concurrent processes can both attempt creation and diverge.
⚠️		Startup	The default database bootstrap path depends on a pre-creation connection that may fail on empty catalogs, so CREATE DATABASE for the configured default is never executed.
⚠️		Startup	Default database bootstrap is not robust: connection preconditions can fail before CREATE DATABASE executes, so expected first-boot side effects are missing.

Additional Findings Details

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

🟠 Bind accepts extra parameter format codes

• Severity: High
• Description: Expected behavior is a Bind-time rejection for mismatched format-code list length, but the server accepts the payload and executes the statement.
• Impact: The server accepts a Bind message with more format codes than parameters and continues executing the statement instead of rejecting the malformed request. That can let an invalid client request proceed silently through a core database protocol step, producing incorrect query execution behavior for connected applications.
• Steps to Reproduce:
  1. Prepare a statement with two parameters and confirm the parameter count from Describe.
  2. Send a Bind for that statement with two parameter values but three parameter format codes.
  3. Execute the portal and observe BindComplete/DataRow/CommandComplete instead of a Bind-time format-code length error.
• Stub / mock content: A test-only authentication bypass was enabled during execution so the protocol harness could connect in the local QA environment; this setup change does not alter Bind format-code validation logic.
• Code Analysis: In server/doltgres_handler.go, convertBindParameters calls extendFormatCodes(len(values), formatCodes). extendFormatCodes rejects only len(formatCodes) < fieldLength when more than one code is supplied, and returns the slice unchanged for len(formatCodes) >= fieldLength. convertBindParameters then indexes formatCodes only across existing values, so trailing extra codes are silently ignored. The PR diff is limited to dependency files (go.mod and go.sum) and does not modify this handler path, so introduced_by_this_pr is False.

Evidence Package

• text/PREPARED-4/PREPARED-4-bind-format-code-mismatch-evidence.txt — 2 KB

🟠 COPY FROM accepts unrestricted server file paths

• Severity: High
• Description: Unsafe absolute file paths were accepted and ingested by COPY FROM instead of being constrained or rejected.
• Impact: COPY FROM can read arbitrary server file paths, so a user can ingest sensitive local files instead of being blocked. This exposes confidential data through a normal query flow and should be treated as a serious security issue.
• Steps to Reproduce:
  1. Connect to the server and create a table for COPY ingestion.
  2. Run COPY copy_test FROM '/etc/passwd'.
  3. Observe that the command succeeds (COPY 19) and rows are loaded instead of the path being blocked.
• Stub / mock content: Authentication was intentionally disabled in the QA run to execute protocol tests quickly, but no COPY-specific mocks, stubs, or bypasses altered file path handling for this test.
• Code Analysis: In copyFromFileQuery, the handler directly opens stmt.File via os.Open without canonicalization, allowlisting, or privilege/path guards, despite an inline TODO noting missing security checks. The same path then calls dataLoader.Finish and returns COPY , which matches the observed successful ingestion of '/etc/passwd'.

Evidence Package

• text/QUERY-4/QUERY-4-copy-from-unrestricted-paths.txt — 2 KB

🟠 Concurrent first-boot default database creation collision

• Severity: High
• Description: Startup does not enforce a single initializer for first-boot default database creation, so concurrent processes can both attempt creation and diverge.
• Impact: Two instances starting against the same empty data directory can race during first-run initialization, leaving one startup path broken and the default database missing or inconsistent. Users may be unable to bring the service up cleanly without manual recovery.
• Steps to Reproduce:
  1. Prepare a clean shared DOLTGRES_DATA_DIR with no existing databases.
  2. Start two doltgres processes nearly simultaneously, both pointing at that same directory.
  3. Observe startup logs and catalog results showing one process may fail or report missing/default DB anomalies after competing CREATE DATABASE attempts.
• Stub / mock content: The run used a test-only authentication bypass so automation could drive concurrent startup checks, but default database initialization itself was exercised through normal production startup code without mocks or simulated database responses.
• Code Analysis: runServer computes initializeDefaultDatabase from a pre-start directory scan (server/server.go:140-149), then each started process independently calls createDefaultDatabase when that flag is true (server/server.go:182-187). createDefaultDatabase executes a plain CREATE DATABASE statement with no synchronization or IF NOT EXISTS handling (server/server.go:214-215), so concurrent first-boot processes can race and one can fail. The smallest practical fix is to make initialization idempotent under concurrency (for example, handle already-exists as success for the configured default DB, or guard initialization with a cross-process lock around the create path).

Evidence Package

• text/STARTUP-4/STARTUP-4-concurrent-first-boot-collision.txt — 3 KB

🟡 Cold startup skips configured default database creation

• Severity: Medium
• Description: The default database bootstrap path depends on a pre-creation connection that may fail on empty catalogs, so CREATE DATABASE for the configured default is never executed.
• Impact: Cold starts can fail to create the configured default database, leaving the server unable to accept normal connections until the startup path is fixed or worked around.
• Steps to Reproduce:
  1. Start doltgres with a brand-new DOLTGRES_DATA_DIR and set DOLTGRES_DB to a target name such as getting_started.
  2. Wait for startup and inspect startup logs and initial connection behavior.
  3. Observe that startup logs show missing implicit databases (for example postgres/root) and the configured default database is not created.
• Stub / mock content: The run used a local test bypass that disabled wire-protocol authentication and launched a rebuilt /tmp/doltgres-test binary; these changes affect login gating but do not alter the default-database creation logic analyzed in server startup.
• Code Analysis: runServer triggers createDefaultDatabase on first startup (server/server.go:182-187). In createDefaultDatabase, the DSN omits a database name (server/server.go:204), so pgx.Connect may target an implicit database before the configured default exists; if that implicit target is absent, connection fails and execution never reaches CREATE DATABASE at server/server.go:214. The smallest practical fix is to connect using an always-available bootstrap database (or a direct bootstrap path that does not require the target database to pre-exist) before issuing CREATE DATABASE for DOLTGRES_DB.

Evidence Package

• text/STARTUP-1/STARTUP-1-startup-runtime-evidence.txt — 3 KB
• text/STARTUP-1/STARTUP-1-startup-code-path-evidence.txt — 938 B

🟡 Default database is not reliably created before replication startup failure

• Severity: Medium
• Description: Default database bootstrap is not robust: connection preconditions can fail before CREATE DATABASE executes, so expected first-boot side effects are missing.
• Impact: A replication-startup failure can prevent the configured default database from being created during bootstrap, leaving the application in a partially initialized state. Users may be unable to complete startup recovery cleanly in empty environments.
• Steps to Reproduce:
  1. Start doltgres with an empty data directory and set DOLTGRES_DB to a non-default database name.
  2. Allow runServer to reach the initializeDefaultDatabase path on first boot.
  3. Observe createDefaultDatabase building a DSN without an explicit database and calling pgx.Connect before CREATE DATABASE.
  4. If that connection fails against an empty catalog, startup exits before creating the configured default database.
• Stub / mock content: The test harness disabled wire-protocol authentication by setting EnableAuthentication to false in server/authentication_scram.go to allow local execution; this does not change the default-database bootstrap logic under test.
• Code Analysis: In server/server.go, runServer calls createDefaultDatabase after server start (lines 182-187) and before replication startup (lines 189-193). Inside createDefaultDatabase, the DSN omits a database component (line 204) and pgx.Connect is attempted first (lines 208-210); CREATE DATABASE only runs afterward (line 214). On empty catalogs this ordering can fail before database creation, which matches the missing-default-database behavior. A targeted fix is to connect to a guaranteed system database (or include explicit fallback logic) before issuing CREATE DATABASE for the configured default name.

Evidence Package

• text/STARTUP-3/STARTUP-3-default-db-bootstrap-evidence.txt — 2 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18269	18268
Failures	23821	23822
Partial Successes1	5333	5333

	Main	PR
Successful	43.4046%	43.4022%
Failures	56.5954%	56.5978%

${\color{red}Regressions (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);
RECEIVED ERROR: expected row count 0 but received 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. ↩

[github-actions]

This PR has been superseded by #2848