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

[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	1923.93/s	${\color{red}DNF}$
groupby_scan_postgres	115.41/s	${\color{red}DNF}$
index_join_postgres	682.43/s	${\color{red}DNF}$
index_join_scan_postgres	847.77/s	${\color{red}DNF}$
index_scan_postgres	24.20/s	${\color{red}DNF}$
oltp_delete_insert_postgres	823.82/s	${\color{red}DNF}$
oltp_insert	721.91/s	${\color{red}DNF}$
oltp_point_select	3027.99/s	${\color{red}DNF}$
oltp_read_only	2975.43/s	${\color{red}DNF}$
oltp_read_write	2269.17/s	${\color{red}DNF}$
oltp_update_index	738.52/s	${\color{red}DNF}$
oltp_update_non_index	728.73/s	${\color{red}DNF}$
oltp_write_only	1707.32/s	${\color{red}DNF}$
select_random_points	1869.89/s	${\color{red}DNF}$
select_random_ranges	1094.34/s	${\color{red}DNF}$
table_scan_postgres	22.86/s	${\color{red}DNF}$
types_delete_insert_postgres	777.79/s	${\color{red}DNF}$
types_table_scan_postgres	10.06/s	${\color{red}DNF}$

[itoqa]

Ito Test Report ✅

12 test cases ran. 1 additional finding, 11 passed.

Across 12 regression and protocol tests, 11 passed and 1 failed, with parser resilience, prepared-statement bind planning, startup/bootstrap behavior, permission enforcement, handshake readiness, normal COPY synchronization, and duplicate CopyDone recovery all behaving as expected.
The most important finding is a High-severity confirmed bug in server/connection_handler.go where an out-of-order Query is accepted and executed during active COPY FROM STDIN instead of being rejected until CopyDone or CopyFail, creating protocol-state desynchronization risk and potentially breaking core data-ingest workflows with no reliable client-side workaround.

✅ Passed (11)

Category	Summary	Screenshot
Bootstrap	Fresh first-run bootstrap created and exposed the postgres default database successfully.
Bootstrap	Injected CREATE DATABASE bootstrap failure recovered cleanly after restart, with postgres connectable.
Parser	Malformed SQL returned a controlled syntax error, and the same session immediately succeeded on SELECT 1 and DEALLOCATE ALL.
Parser	CREATE TABLE, INSERT, and SELECT completed successfully with expected command tags and returned rows.
Permissions	Unprivileged SELECT is correctly denied with a permission error.
Prepared	Controlled ambiguous bind coercion error was returned and the connection stayed healthy for follow-up queries.
Prepared	Parse with empty ParameterOIDs inferred types correctly and inserted/query-backed data matched expectations.
Prepared	Re-parsing the same prepared statement name produced deterministic type replacement without mixed metadata behavior.
Wire	Startup authentication completed and SELECT 1 executed immediately after connect.
Wire	COPY FROM STDIN imported rows and normal query execution resumed afterward.
Wire	Duplicate CopyDone was rejected and the session recovered for subsequent queries.

ℹ️ Additional Findings (1)

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

Category	Summary	Screenshot
Wire	⚠️ Out-of-order Query messages are accepted and executed while COPY FROM STDIN is still active.	N/A

⚠️ Out-of-order query accepted during COPY

• What failed: The server executes the out-of-order query during COPY mode instead of rejecting it until COPY mode is terminated, breaking copy-mode message boundary enforcement.
• Impact: Clients can interleave non-COPY commands into an active COPY stream, which can desynchronize protocol state and break core data-ingest workflows. There is no reliable client-side workaround once the server accepts invalid message ordering.
• Steps to reproduce:
  1. Start COPY FROM STDIN so the connection enters copy mode.
  2. Before sending CopyDone or CopyFail, send a Query message on the same connection.
  3. Continue the COPY sequence and observe that the out-of-order query is executed instead of rejected.
• Stub / mock context: The run used local socket-level protocol clients against a non-production Doltgres instance and did not rely on mocked server responses for this defect confirmation. A temporary edit in server/analyzer/domain_constraints.go was present during execution, but the reproduced failure is in server/connection_handler.go COPY state dispatch logic.
• Code analysis: I reviewed COPY state handling in server/connection_handler.go and found that copyFromStdinState is set for COPY mode, and COPY-specific handlers enforce state checks, but the top-level message dispatcher still routes Query unconditionally without guarding for active COPY mode.
• Why this is likely a bug: The code explicitly tracks COPY mode and rejects invalid COPY-state messages, so accepting Query while copyFromStdinState is active is an inconsistent state-machine branch in production message dispatch logic.

Relevant code:

server/connection_handler.go (lines 400-430)

func (h *ConnectionHandler) handleMessage(msg pgproto3.Message) (stop, endOfMessages bool, err error) {
	switch message := msg.(type) {
	case *pgproto3.Terminate:
		return true, false, nil
	case *pgproto3.Sync:
		h.waitForSync = false
		return false, true, nil
	case *pgproto3.Query:
		endOfMessages, err = h.handleQuery(message)
		return false, endOfMessages, err
	case *pgproto3.CopyData:
		return h.handleCopyData(message)
	case *pgproto3.CopyDone:
		return h.handleCopyDone(message)
	}
}

server/connection_handler.go (lines 65-67)

// copyFromStdinState is set when this connection is in the COPY FROM STDIN mode, meaning it is waiting on
// COPY DATA messages from the client to import data into tables.
copyFromStdinState *copyFromStdinState

server/connection_handler.go (lines 769-770)

if copyState == nil {
	return false, true, errors.Errorf("COPY DATA message received without a COPY FROM STDIN operation in progress")
}

Commit: 5f64f07

View Full Run

---

Tell us how we did: Give Ito Feedback