[adsharma]

Concurrent write transactions are production-ready, so the debug_ prefix has to go.

What changed

• Setting renamed: debug_enable_multi_writes -> enable_multi_writes (consistent with SystemConfig::enableMultiWrites and the other enable_* settings).
• C++ struct renamed: EnableMVCCSetting -> EnableMultiWritesSetting; dropped the stale TODO calling it a temporary test solution.
• Default flipped from false to true in SystemConfig.
• Updated all CALL sites (e2e .test files, transaction_test.cpp, checkpoint_test.cpp, node_write_bench.cpp).
• ddl_serial_execution.test MultiWritesException case now opts out explicitly with CALL enable_multi_writes=false so single-writer mode stays covered; the EnableMultiWrites case now exercises the false->true toggle.

Verified locally

• ninja -C build/release lbug builds clean.
• e2e concurrency suites pass (27 tests): ddl_serial, ddl_concurrent, dml_empty_serial, dml_tinysnb_serial.

Companion binding PRs

Each binding now lets the engine control defaults (unset = engine default), so no binding pins a copy of these defaults anymore:

• Python: feat(config): let the engine control SystemConfig defaults ladybug-python#77
• Java: feat(config): let the engine control SystemConfig defaults ladybug-java#18
• Rust: feat(config): let the engine control SystemConfig defaults ladybug-rust#45
• Node.js: feat(config): let the engine control SystemConfig defaults ladybug-nodejs#28
• WASM: feat(config): let the engine control SystemConfig defaults ladybug-wasm#14

[adsharma]

Note: this is 0.23.x material — it flips a user-visible default (multi-writer mode on by default) and renames a setting, so it should ride the 0.23 release, not get backported to a 0.22.x patch.

[adsharma]

Companion binding PRs (same default flip, separate repos since these are submodules here): ladybug-python#76, ladybug-java#17, ladybug-rust#44. nodejs/wasm don't expose the flag, so no change needed there. CI on this PR covers the engine side.

[adsharma]

Update: superseded the default-flip-only binding PRs with fuller ones where each binding lets the engine control all defaults (unset = engine default): ladybug-python#77, ladybug-java#18, ladybug-rust#45, plus nodejs#28 and wasm#14 which needed the same treatment. CI here covers the engine side; each binding repo's CI covers its own.

[zahariash]

I checked this against the open PRs under #1376, simulating the new default on their merge.

Automatic checkpoints wait for other writers. A commit's automatic checkpoint takes the write gate and waits up to 5 s for every other write transaction to leave. In single-writer mode none can be open at that point. Here, one connection held a write transaction open while another committed three single-row writes, with checkpoint_threshold=1:

	Each write	Caller sees
0.22.0, single-writer	0 s	"Only one write transaction at a time" (nothing applied)
0.22.0, multi-writer	5.6 s	"Transaction committed successfully, but the post-commit checkpoint failed" (#1199)
#1376 merge, multi-writer	5.6 s	success, and a stderr warning per commit

With the 16 MB default this starts once the WAL passes the threshold and repeats on every commit while a long write transaction stays open, and new writers wait behind the gate meanwhile. So #1361 should land with or before this PR; otherwise retries of those "failed" commits apply them twice. The 5 s stall stays even with #1361; an automatic checkpoint could skip, instead of waiting, while other write transactions are open.

#1375 still matters. In multi-writer mode a BEGIN is still refused when the WAL is poisoned. With one failed WAL sync injected, 0.22.0 refuses the BEGIN and the connection's next MATCH segfaults (#1316); with #1375 it answers.

Merge notes.

• fix(txn): keep a connection usable after a refused BEGIN #1375's tests rely on the single-writer refusal: RefusedBeginKeepsAutoMode and RefusedPreparedAndMultiStatementBeginKeepAutoMode fail with the new default, and RefusedBeginKeepsConnectionUsable in ddl_serial_execution.test conflicts with this PR's edit there. Whichever lands second needs CALL enable_multi_writes=false in them.
• fix(txn): don't fail a committed write when its automatic checkpoint fails #1361's AutoCheckpointBlockedByOpenWriterDoesNotFailCommit calls debug_enable_multi_writes, which this PR renames without an alias.

Apart from those, transaction_test and the whole e2e suite pass on the #1376 merge with multi-writer mode as the default. I skipped EmptyDBTransactionTest, whose concurrency tests already turn the mode on themselves.

The simulator and the retention loop behind #1436 and #1437 have only run single-writer mode so far; the C stress loop ran multi-writer mode in half of its rounds without a violation.