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

[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	1732.73/s	1722.96/s	-0.6%
index_join_postgres	244.56/s	244.39/s	-0.1%
index_join_scan_postgres	256.50/s	255.98/s	-0.3%
index_scan_postgres	15.97/s	15.94/s	-0.2%
oltp_point_select	3081.30/s	3111.76/s	+0.9%
oltp_read_only	2352.34/s	2336.84/s	-0.7%
select_random_points	167.48/s	166.65/s	-0.5%
select_random_ranges	1125.12/s	1120.20/s	-0.5%
table_scan_postgres	15.59/s	15.50/s	-0.6%
types_table_scan_postgres	7.22/s	7.21/s	-0.2%

[itoqa]

Ito Test Report ✅

6 test cases ran. 1 additional finding, 5 passed.

Overall, the unified run passed 5 of 6 test cases, confirming stable multi-row and mixed-statement query behavior, successful standard startup to ReadyForQuery, and consistent boolean staged semantics in dolt.status across repeated and expanded reads, while two additional executions had no includable pass/fail outcomes. The only failure was a minor startup-protocol defect where malformed SSL/GSS message ordering is rejected by disconnecting without sending an explicit protocol ErrorResponse first, reducing diagnostic clarity even though clean reconnects and normal availability remain unaffected.

✅ Passed (5)

Category	Summary	Screenshot
Query	Using PostgreSQL client against local Doltgres, created qa_stream_test, inserted three rows, and SELECT returned the full dataset without protocol errors.
Query	Executed a mixed query matrix against local Doltgres and observed stable, non-duplicated client-visible results across statement categories, with expected row counts and command tags.
Startup	Startup handshake reached query-ready state and immediate SELECT 1 succeeded.
Status	In qa_status_db, querying dolt.status with boolean predicates (staged IS TRUE / staged IS FALSE) returned correct true/false semantics for both staged and unstaged rows, confirming staged is exposed as boolean behavior rather than raw byte values.
Status	Re-ran dolt.status queries repeatedly and after adding a second table with staged/unstaged changes; row iteration remained stable and returned boolean-like staged semantics without panic or type-conversion failures.

ℹ️ Additional Findings (1)

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

Category	Summary	Screenshot
Startup	🟡 Malformed SSL/GSS ordering is rejected, but no explicit protocol error response is emitted before disconnect.

🟡 Missing explicit startup protocol error response

• What failed: The malformed sequence is rejected and the client sees a reset/broken pipe, but the server does not emit an explicit protocol-level error response before closing the connection as expected by this startup contract.
• Impact: Clients and operators get less actionable protocol diagnostics for malformed startup sequences, which makes integration troubleshooting harder. Normal reconnect still works, so primary availability is not blocked.
• Steps to reproduce:
  1. Open a connection and send SSLRequest, then GSSEncRequest, then an unexpected startup message type before a valid StartupMessage.
  2. Observe server responses and connection behavior.
  3. Attempt a clean reconnect and run SELECT 1.
• Stub / mock context: Authentication was simplified for this run: SCRAM negotiation was bypassed, and authorization checks were allowed to proceed when role metadata was missing so startup protocol behavior could be verified deterministically.
• Code analysis: I reviewed the startup negotiation implementation in server/connection_handler.go. For unexpected startup-message types, handleStartup() returns an error directly; HandleConnection() then exits and closes the connection, which matches the observed reset behavior. The handler has an explicit sendError() path, but it is not used for this startup default branch, so malformed ordering can terminate without a protocol ErrorResponse.
• Why this is likely a bug: The startup path has a direct error-return branch for malformed startup ordering that closes the connection without using the existing protocol error response mechanism, so clients lose the explicit protocol error signal.

Relevant code:

server/connection_handler.go (lines 234-261)

case *pgproto3.SSLRequest:
    hasCertificate := len(certificate.Certificate) > 0
    var performSSL = []byte("N")
    if hasCertificate {
        performSSL = []byte("S")
    }
    _, err = h.Conn().Write(performSSL)
    if err != nil {
        return false, errors.Errorf("error sending SSL request: %w", err)
    }
    return h.handleStartup()
case *pgproto3.GSSEncRequest:
    _, err = h.Conn().Write([]byte("N"))
    if err != nil {
        return false, errors.Errorf("error sending response to GSS Enc Request: %w", err)
    }
    return h.handleStartup()
default:
    return false, errors.Errorf("terminating connection: unexpected start message: %#v", startupMessage)

server/connection_handler.go (lines 178-180)

if proceed, err := h.handleStartup(); err != nil || !proceed {
    returnErr = err
    return
}

server/connection_handler.go (lines 1121-1128)

func (h *ConnectionHandler) sendError(err error) {
    fmt.Println(err.Error())
    if sendErr := h.send(&pgproto3.ErrorResponse{
        Severity: string(ErrorResponseSeverity_Error),
        Code:     "XX000", // internal_error for now
        Message:  err.Error(),
    }); sendErr != nil {

Commit: 53aa3b6

View Full Run

---

Tell us how we did: Give Ito Feedback

[github-actions]

	Main	PR
Total	42090	42090
Successful	18197	18196
Failures	23893	23894
Partial Successes1	5392	5392

	Main	PR
Successful	43.2335%	43.2312%
Failures	56.7665%	56.7688%

${\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. ↩