Permit configured unsupported locking statements

[zachmu]

Adds an opt-in server setting to accept and ignore unsupported locking statements.

This provides a partial workaround for the limitations in #2600

[github-actions]

	Main	PR
Total	42090	42090
Successful	19904	19905
Failures	22186	22185
Partial Successes1	5450	5450

	Main	PR
Successful	47.2891%	47.2915%
Failures	52.7109%	52.7085%

${\color{lightgreen}Progressions (1)}$

subselect

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

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

[coffeegoddd]

@zachmu DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.43	2.43	0.0
groupby_scan_postgres	80.03	80.03	0.0
index_join_postgres	2.22	2.22	0.0
index_join_scan_postgres	1.64	1.61	-1.83
index_scan_postgres	475.79	475.79	0.0
oltp_point_select	0.37	0.37	0.0
oltp_read_only	6.43	6.43	0.0
select_random_points	0.72	0.72	0.0
select_random_ranges	1.04	1.04	0.0
table_scan_postgres	467.3	467.3	0.0
types_table_scan_postgres	1191.92	1191.92	0.0

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.67	0.0
oltp_insert	3.36	3.36	0.0
oltp_read_write	13.46	13.46	0.0
oltp_update_index	3.55	3.55	0.0
oltp_update_non_index	3.25	3.3	1.54
oltp_write_only	7.04	7.04	0.0
types_delete_insert_postgres	7.17	7.17	0.0

[itoqa]

Commit: 7cca761: 14 test cases ran, 14 passed ✅.

Summary

Coverage exercises the database’s handling of row-locking queries across opt-in and default configurations, startup modes, prepared and mixed statements, connection recovery, concurrent updates, and ordinary-query compatibility. It includes happy paths, boundary and failure-recovery scenarios, concurrency behavior, and regression checks for unchanged query results.

Safe to merge — the run found no failures or regressions attributable to this PR, and the covered locking, recovery, concurrency, configuration, and ordinary-query behaviors all passed. No merge-blocking risk was identified.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	Servers with no setting or an explicit false setting rejected the locking query, while the true setting returned row 1 as expected.
✅	—	General	The mixed query reported its expected locking error, and the same connection later ran SELECT 1 and returned 1.
✅	—	General	The first query returned the expected unsupported-locking error, and the next query on the same connection returned row 1.
✅	—	General	The configured in-memory and local-filesystem servers both accepted the locking query and returned rows 1 and 2.
✅	—	General	The client sent two locking queries to the configured server, and both returned rows 1 and 2 without an error.
✅	—	General	The server accepted the locking query immediately after startup and returned rows 1 and 2.
✅	—	Configuration	The script test started an in-memory server with locking support enabled and returned rows 1 and 2 from the locking query.
✅	—	Conversion	The database accepted SELECT 1 + 1 and returned 2 in the result column.
✅	—	Default	A query with FOR UPDATE was rejected with the expected unsupported-locking error when the setting was absent.
✅	—	Locking	With the opt-in setting enabled, the server accepted the FOR UPDATE query and returned rows 1 and 2. The default rejection check also passed.
✅	—	Rev	A server with the YAML setting enabled accepted FOR UPDATE and other locking queries, and returned rows 1 and 2 in order.
✅	—	Rev	The prepared query completed successfully and returned rows 1 and 2 in primary-key order without an unsupported-locking error.
✅	—	Rev	The first session used FOR UPDATE without taking a lock, so the second session updated the row and read back the committed value 99.
✅	—	Rev	The same ordinary query returned identical rows in default and permissive server modes, including the NULL value, row order, and aggregate count.

Tip

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

[fulghum]

LGTM