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

[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	1841.43/s	1795.13/s	-2.6%
groupby_scan_postgres	133.79/s	134.21/s	+0.3%
index_join_postgres	643.04/s	642.59/s	-0.1%
index_join_scan_postgres	787.04/s	780.14/s	-0.9%
index_scan_postgres	26.86/s	26.06/s	-3.0%
oltp_delete_insert_postgres	785.39/s	760.07/s	-3.3%
oltp_insert	680.23/s	680.01/s	-0.1%
oltp_point_select	2846.94/s	2759.36/s	-3.1%
oltp_read_only	2883.01/s	2829.91/s	-1.9%
oltp_read_write	2271.94/s	2285.64/s	+0.6%
oltp_update_index	714.08/s	719.47/s	+0.7%
oltp_update_non_index	748.64/s	740.31/s	-1.2%
oltp_write_only	1724.14/s	1700.52/s	-1.4%
select_random_points	1827.46/s	1817.97/s	-0.6%
select_random_ranges	1072.82/s	1051.41/s	-2.0%
table_scan_postgres	25.19/s	24.25/s	-3.8%
types_delete_insert_postgres	764.95/s	751.14/s	-1.9%
types_table_scan_postgres	11.19/s	10.80/s	-3.5%

[itoqa]

Commit: f45cd11: 5 test cases ran, 3 passed ✅, 2 additional findings ⚠️.

Summary

This run covered core database behavior across normal query execution and parameter handling, data durability through schema changes and reconnects, and resilience-focused scenarios around file import safety and replication startup health signaling. Overall product behavior appears stable for the change under review, with failures concentrated in broader security and operational-health areas rather than core request/response correctness.

Safe to merge — no regressions or still-failing issues attributable to this PR were identified, so the current change appears low risk. There are serious pre-existing findings in security and startup health reporting, but they are not caused by this PR and are better tracked as separate follow-up work.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Prepared	Extended-protocol Parse requests with OID 0 parameters completed successfully, and subsequent Bind/Execute calls returned the expected typed results for both int+text and numeric parameter cases.
✅	—	Query	The wire-protocol query path returned one RowDescription, 5000 DataRow messages in order, one CommandComplete (SELECT 5000), and one ReadyForQuery, matching the expected single-completion behavior for a large streamed result.
✅	—	Storage	The create-insert-rename-drop lifecycle remained consistent across reconnect: the renamed table persisted with all 3 rows, the dropped table stayed removed, and catalog lookups remained coherent without serialization errors.
⚠️		Copy	Unsafe file path attempts were expected to fail safely, but COPY succeeded and imported sensitive host file content.
⚠️		Startup	Expected replication failure to be surfaced promptly and unambiguously after startup when the upstream is unreachable. Actual behavior shows the server as ready with HTTP 200 metrics and no replication status signal while the replicator logs connection failures and exits.

Additional Findings Details

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

🔴 COPY FROM allows arbitrary local file reads

• Severity: Critical
• Description: Unsafe file path attempts were expected to fail safely, but COPY succeeded and imported sensitive host file content.
• Impact: Authenticated users who can run COPY FROM can read sensitive host files such as /etc/passwd and /etc/shadow through SQL results. This can expose credential hashes and system account data from the database host.
• Steps to Reproduce:
  1. Create a single-column destination table and connect with SQL access.
  2. Run COPY FROM '/etc/passwd' and COPY FROM '/etc/shadow' into that table shape.
  3. Query the destination tables and confirm real host file rows are returned.
• Stub / mock content: The run disabled authentication to keep a local superuser session for exercising COPY behavior, and no mocks or route interceptions altered the COPY file path logic under test.
• Code Analysis: In server/connection_handler.go, copyFromFileQuery opens stmt.File directly via os.Open without any path allowlist, traversal guard, or privilege gate, and the in-repo integration test suite also marks secure_file_priv enforcement as not yet supported. A targeted fix is to enforce secure_file_priv/path policy and privilege checks in copyFromFileQuery before os.Open, rejecting absolute and traversal paths outside the allowed directory.

Evidence Package

• text/COPY-1/COPY-1-copy-from-arbitrary-file-read.txt — 3 KB

🟠 Startup reports healthy despite failed replication

• Severity: High
• Description: Expected replication failure to be surfaced promptly and unambiguously after startup when the upstream is unreachable. Actual behavior shows the server as ready with HTTP 200 metrics and no replication status signal while the replicator logs connection failures and exits.
• Impact: Replication can fail at startup while the service still appears healthy, so operators may continue serving stale or incomplete replicated data without realizing synchronization is down.
• Steps to Reproduce:
  1. Start doltgres with valid replication configuration and confirm baseline replication works.
  2. Stop upstream PostgreSQL so the replication source is unavailable.
  3. Restart doltgres with replication still enabled.
  4. Observe server startup state, metrics endpoint, and replication logs/SQL status views.
• Stub / mock content: No mocks, stubs, or bypasses were used; the test simulated a real upstream outage by stopping the local PostgreSQL source before restarting doltgres.
• Code Analysis: In server/server.go, runServer starts SQL services, waits for startup success, then calls startReplication, which launches replicator.StartReplication in a goroutine and immediately returns success without wiring replication state into readiness or startup failure handling. In server/logrepl/replication.go, StartReplication retries connection errors, then returns an error and calls shutdown, but because it runs in a detached goroutine the failure is only logged. In server/tables/pgcatalog/pg_replication_slots.go and server/tables/pgcatalog/pg_stat_replication.go, RowIter methods are TODO stubs returning empty iterators, matching the observed empty SQL status views and lack of an unambiguous runtime replication health signal.

Evidence Package

• text/STARTUP-1/STARTUP-1-repro-and-runtime-evidence.txt — 3 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18275	18274
Failures	23815	23816
Partial Successes1	5335	5335

	Main	PR
Successful	43.4189%	43.4165%
Failures	56.5811%	56.5835%

${\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 #2912