test hash changes

[jycor]

No description provided.

[github-actions]

	Main	PR
covering_index_scan_postgres	1907.63/s	1924.03/s	+0.8%
groupby_scan_postgres	131.06/s	133.91/s	+2.1%
index_join_postgres	674.91/s	674.85/s	-0.1%
index_join_scan_postgres	868.03/s	856.38/s	-1.4%
index_scan_postgres	25.35/s	25.32/s	-0.2%
oltp_delete_insert_postgres	848.59/s	838.59/s	-1.2%
oltp_insert	735.30/s	722.55/s	-1.8%
oltp_point_select	3052.51/s	3052.56/s	0.0%
oltp_read_only	2994.64/s	3059.78/s	+2.1%
oltp_read_write	2341.64/s	2294.77/s	-2.1%
oltp_update_index	755.00/s	735.81/s	-2.6%
oltp_update_non_index	831.19/s	782.38/s	-5.9%
oltp_write_only	1803.23/s	1797.34/s	-0.4%
select_random_points	1861.86/s	1943.28/s	+4.3%
select_random_ranges	1099.68/s	1101.93/s	+0.2%
table_scan_postgres	24.11/s	23.85/s	-1.1%
types_delete_insert_postgres	816.15/s	806.33/s	-1.3%
types_table_scan_postgres	8.55/s	8.40/s	-1.8%

[itoqa]

Commit: 1820da1: 11 test cases ran, 0 failed ❌, 10 passed ✅, 1 additional finding ⚠️.

Summary

Coverage exercised core database behavior across connection startup, query execution in both simple and prepared/bound flows, planner and metadata consistency, and data ingest paths including normal and failure-oriented transaction scenarios. Overall behavior looked stable for the areas touched, with expected results across happy paths and edge-case error handling.

Safe to merge — the exercised query, protocol, startup, and ingest behaviors were broadly healthy for this PR’s scope, and no regression was identified as introduced by this change. A serious ingest transaction-semantics defect is present but was identified as pre-existing rather than caused by this PR, so it is a follow-up risk rather than an immediate merge blocker for this diff.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Binding	The extended protocol prepared statement flow returned the expected rows for bound values 1 and 2 and returned zero rows for 99, then deallocated cleanly.
✅	—	Binding	RowDescription metadata remained consistent with DataRow payload decoding across explicit casts, declared param typing, alias preservation, text coercion, and multi-column outputs.
✅	—	Engine	The simple Query protocol returned three ordered employee rows with expected column metadata, and the blocked runner status was caused by harness-level batch execution issues rather than application behavior.
✅	—	Engine	Scalar subqueries that returned two rows were rejected with error 1242 ("the subquery returned more than 1 row") across both simple and extended query protocols, so max-one-row enforcement remained intact after the engine dependency upgrade.
✅	—	Engine	Regression coverage across SELECT, DML with RETURNING, advanced queries, transactions, and type/cast execution found no new engine-integration failures after the go-mysql-server upgrade. PREPARE/EXECUTE and window-function-in-CTE errors observed during the run match known pre-existing Doltgres limitations.
✅	—	Ingest	COPY FROM STDIN succeeded in both CSV and default TEXT modes, and row counts plus row visibility checks confirmed the streamed rows were persisted.
✅	—	Ingest	COPY FROM a conflicting CSV failed with a duplicate-key error, preserved zero persisted rows, and remained retry-safe until a clean file loaded successfully with COPY 3.
✅	—	Ingest	CopyFail after accepted COPY STDIN data consistently aborts the ingest, preserves zero persisted rows on conflicting retries, and allows a clean retry to commit the expected rows.
✅	—	Startup	A fresh connection to localhost:5432 as postgres/password reached ReadyForQuery and executed SELECT 1 successfully.
✅	—	Startup	A startup request targeting definitely_missing_db correctly failed with a FATAL ErrorResponse carrying SQLSTATE 3D000 and the expected database-not-found message.
⚠️		Ingest	Expected behavior is that ROLLBACK removes both the table and copied rows from the explicit transaction. Actual behavior persists the table and rows after ROLLBACK, while COMMIT behaves as expected.

Additional Findings Details

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

🟠 COPY rollback commits rows

• Severity: High
• Description: Expected behavior is that ROLLBACK removes both the table and copied rows from the explicit transaction. Actual behavior persists the table and rows after ROLLBACK, while COMMIT behaves as expected.
• Impact: Users can believe a rollback succeeded while COPY-ingested rows and table creation remain committed, causing unintended persistent data and incorrect database state.
• Steps to Reproduce:
  1. Run BEGIN; CREATE TABLE ingest2_copy_test(...); COPY ingest2_copy_test FROM STDIN WITH 5 rows; ROLLBACK;.
  2. Query ingest2_copy_test in the same session and in a fresh session.
  3. Observe that the table and all 5 rows still exist after ROLLBACK.
• Stub / mock content: The run used a local authentication bypass to allow scripted test connections; no COPY, transaction, or query behavior was mocked or stubbed for this test.
• Code Analysis: In server/connection_handler.go, handleCopyDone calls CommitTransaction unconditionally after dataLoader.Finish (lines 920-931), which commits COPY work even inside an explicit BEGIN/ROLLBACK flow. The same file tracks Begin/Commit state in handleQueryOutsideEngine (lines 491-494), but the rollback path cannot undo work already committed at CopyDone. Smallest practical fix: in handleCopyDone, do not auto-commit when COPY is running inside a user-managed transaction, and only end COPY mode without closing that transaction.

Evidence Package

• text/INGEST-2/INGEST-2-copy-rollback-evidence.txt — 2 KB

Tip

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

[github-actions]

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

	Main	PR
Successful	43.4189%	43.4189%
Failures	56.5811%	56.5811%

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. ↩