audited error codes

[zachmu]

This PR audits error code processing to ensure that all common error codes typically examined by clients are correctly returned by the server. In particular, some clients interpret an XX000 error code by terminating the connection to the server, so we need to be careful to only return that code on a catastrophic, unexpected error.

Also adds new client library tests that ensure clients behave as expected in response to these codes.

[github-actions]

	Main	PR
covering_index_scan_postgres	2090.27/s	2046.25/s	-2.2%
groupby_scan_postgres	150.05/s	154.56/s	+3.0%
index_join_postgres	668.30/s	676.63/s	+1.2%
index_join_scan_postgres	843.70/s	844.14/s	0.0%
index_scan_postgres	31.87/s	31.73/s	-0.5%
oltp_delete_insert_postgres	783.57/s	818.84/s	+4.5%
oltp_insert	737.52/s	718.04/s	-2.7%
oltp_point_select	3508.60/s	3460.39/s	-1.4%
oltp_read_only	3483.15/s	3409.21/s	-2.2%
oltp_read_write	2591.04/s	2578.98/s	-0.5%
oltp_update_index	749.12/s	745.70/s	-0.5%
oltp_update_non_index	794.02/s	777.36/s	-2.1%
oltp_write_only	1812.64/s	1833.70/s	+1.1%
select_random_points	2159.99/s	2145.20/s	-0.7%
select_random_ranges	1632.30/s	1582.85/s	-3.1%
table_scan_postgres	31.14/s	31.64/s	+1.6%
types_delete_insert_postgres	809.63/s	830.75/s	+2.6%
types_table_scan_postgres	14.19/s	14.05/s	-1.0%

[github-actions]

	Main	PR
Total	42090	42090
Successful	18407	18406
Failures	23683	23684
Partial Successes1	5327	5327

	Main	PR
Successful	43.7325%	43.7301%
Failures	56.2675%	56.2699%

${\color{red}Regressions (1)}$

subselect

QUERY:          select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);
RECEIVED ERROR: timeout during Receive

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

[itoqa]

Commit: b5ff296: 19 test cases ran, 19 passed ✅.

Summary

Coverage spans core database behavior, including normal reads and writes, arithmetic and timestamp boundary conditions, invalid input handling, error-code and message preservation, constraint and catalog failures, transaction rollback, connection recovery, and concurrent update retries. The run primarily exercises backend correctness, edge cases, and adversarial failure-and-recovery paths, with no application behavior showing a regression.

Safe to merge — all exercised application behaviors passed, with no regressions, new failures, or previously flagged failures attributable to this PR. Some broader client-environment scenarios were unavailable, but they produced no product failure and are a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Data	Dividing by zero reports the expected database error for integer, numeric, and double-precision values. Dividing by two still returns the correct finite result.
✅	—	Data	Adding past the largest signed integer and subtracting below the smallest return an out-of-range error. Valid zero multiplication and in-range addition return the expected values.
✅	—	Data	Timestamp values at and inside the supported range kept the same UTC meaning in two client sessions. Values outside the representable range returned the expected out-of-range error.
✅	—	Driver	The available client checks returned the expected error codes and the connection stayed usable afterward. The full comparison could not run because the local test environment did not provide the required client runtimes and Go harness setup.
✅	—	Driver	The available client received the expected error details and stayed usable after the failed statement. The other driver checks were not run because their runtimes and the local target were unavailable, so this result does not show a product failure.
✅	—	Driver	The retry scenario could not reach the local database service, so no user-facing retry failure was confirmed. Source review shows the test covers rollback, connection reuse, and retry behavior when the service is available.
✅	—	Driver	The server code supports the expected serialization error and lets a client recover for another write. The recorded run was reclassified as a pass because the local database target and the Ruby client environment were unavailable, not because the product showed a failure.
✅	—	Integrity	Duplicate, foreign-key, check, and required-value errors returned their expected PostgreSQL codes. After each rollback, the same connection accepted a valid insert and read.
✅	—	Integrity	New tables, sequences, indexes, and views were created successfully. Repeating the creations returned the expected duplicate error, skip-if-present commands succeeded, and the replaced view returned the expected data.
✅	—	Integrity	Unknown tables and schemas returned 42P01, unknown columns returned 42703, unknown functions returned 42883, and unknown types returned 42704. The same session still completed SELECT 1 afterward, and a separate connection to a missing database was rejected as expected.
✅	—	Integrity	The database reported the duplicate key error, kept the transaction blocked until rollback, and then accepted a new insert and read on the original connection.
✅	—	Sqlstate	A duplicate key error kept SQLSTATE 23505 and its original message. The connection then rejected work until rollback and successfully ran SELECT 42 afterward.
✅	—	Sqlstate	Unknown failures are mapped to the internal error code XX000 and keep their original message. The supported client operations did not include a way to create an unknown failure, so the test could not exercise that fallback but found no application defect.
✅	—	Sqlstate	Representative database errors returned the expected error codes and messages, and a follow-up query succeeded.
✅	—	Sqlstate	Direct and nested invalid integer values both returned 22P02 with the same message. A valid query worked after each error.
✅	—	Transaction	A division-by-zero error was followed by a successful SELECT 1 on the same connection. The session recovered without needing an explicit rollback.
✅	—	Transaction	A duplicate insert failed inside an explicit transaction, and the connection correctly rejected work until rollback. After rollback, the same connection completed a query and a new insert successfully.
✅	—	Transaction	The first conflict check used the wrong commit order and never asked the losing session to commit. A corrected same-run check produced one winning commit, recovered the other session after rollback, and completed a retry successfully.
✅	—	Transaction	Two sessions tried to change the same row. The losing session received a serialization failure, rolled back, and then completed a new update and commit successfully.

Tip

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

[itoqa]

Ito Diff Report — b5ff296 → 4c1f810: 2 test cases ran, 2 passing ✅.

Diff Summary

The run covered database error handling for malformed queries and unsupported types, including correct error classification, clean client-facing behavior, and recovery for subsequent queries. This represents adversarial edge cases alongside basic post-error usability and session health.

Safe to merge — the exercised error-handling and recovery behaviors showed no regressions or new failures attributable to this PR. There are no merge-blocking findings in this run.

Tests run by Ito

Result	State	Severity	Type	Description
✅	Passing	—	Sqlstate	A malformed query returned the expected syntax error to the client, and the server did not print a duplicate error line.
✅	Passing	—	Sqlstate	An unsupported type query returned the expected undefined-object error, and a fresh query worked afterward. The server did not print a duplicate error message.
⏸️	Skipped	—	Data	Dividing by zero reports the expected database error for integer, numeric, and double-precision values. Dividing by two still returns the correct finite result.
⏸️	Skipped	—	Data	Adding past the largest signed integer and subtracting below the smallest return an out-of-range error. Valid zero multiplication and in-range addition return the expected values.
⏸️	Skipped	—	Data	Timestamp values at and inside the supported range kept the same UTC meaning in two client sessions. Values outside the representable range returned the expected out-of-range error.
⏸️	Skipped	—	Driver	The available client checks returned the expected error codes and the connection stayed usable afterward. The full comparison could not run because the local test environment did not provide the required client runtimes and Go harness setup.
⏸️	Skipped	—	Driver	The available client received the expected error details and stayed usable after the failed statement. The other driver checks were not run because their runtimes and the local target were unavailable, so this result does not show a product failure.
⏸️	Skipped	—	Driver	The retry scenario could not reach the local database service, so no user-facing retry failure was confirmed. Source review shows the test covers rollback, connection reuse, and retry behavior when the service is available.
⏸️	Skipped	—	Driver	The server code supports the expected serialization error and lets a client recover for another write. The recorded run was reclassified as a pass because the local database target and the Ruby client environment were unavailable, not because the product showed a failure.
⏸️	Skipped	—	Integrity	Duplicate, foreign-key, check, and required-value errors returned their expected PostgreSQL codes. After each rollback, the same connection accepted a valid insert and read.
⏸️	Skipped	—	Integrity	New tables, sequences, indexes, and views were created successfully. Repeating the creations returned the expected duplicate error, skip-if-present commands succeeded, and the replaced view returned the expected data.
⏸️	Skipped	—	Integrity	Unknown tables and schemas returned 42P01, unknown columns returned 42703, unknown functions returned 42883, and unknown types returned 42704. The same session still completed SELECT 1 afterward, and a separate connection to a missing database was rejected as expected.
⏸️	Skipped	—	Integrity	The database reported the duplicate key error, kept the transaction blocked until rollback, and then accepted a new insert and read on the original connection.
⏸️	Skipped	—	Sqlstate	A duplicate key error kept SQLSTATE 23505 and its original message. The connection then rejected work until rollback and successfully ran SELECT 42 afterward.
⏸️	Skipped	—	Sqlstate	Unknown failures are mapped to the internal error code XX000 and keep their original message. The supported client operations did not include a way to create an unknown failure, so the test could not exercise that fallback but found no application defect.
⏸️	Skipped	—	Sqlstate	Representative database errors returned the expected error codes and messages, and a follow-up query succeeded.
⏸️	Skipped	—	Sqlstate	Direct and nested invalid integer values both returned 22P02 with the same message. A valid query worked after each error.
⏸️	Skipped	—	Transaction	A division-by-zero error was followed by a successful SELECT 1 on the same connection. The session recovered without needing an explicit rollback.
⏸️	Skipped	—	Transaction	A duplicate insert failed inside an explicit transaction, and the connection correctly rejected work until rollback. After rollback, the same connection completed a query and a new insert successfully.
⏸️	Skipped	—	Transaction	The first conflict check used the wrong commit order and never asked the losing session to commit. A corrected same-run check produced one winning commit, recovered the other session after rollback, and completed a retry successfully.
⏸️	Skipped	—	Transaction	Two sessions tried to change the same row. The losing session received a serialization failure, rolled back, and then completed a new update and commit successfully.

Tip

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

[Hydrocharged]

LGTM! I support this new error code direction