Conversation
The batch-insert optimisation in the apply worker was gated by spock.batch_inserts and relied on accumulating consecutive inserts to the same relation before flushing them via heap_multi_insert(). The logic was disabled entirely when use_try_block was active, and had acknowledged correctness concerns around snapshot semantics and command-counter visibility for subsequently replicated DML that needed to see those tuples. Remove the feature entirely: drop the GUC, the ApplyMIState struct, the spkmistate static variable, multi_insert_finish() and all its call sites, and the spock_apply_heap_mi_*() family of functions. Remove matching documentation (batch_inserts.md, configuring.md, conflicts.md, managing/index.md, mkdocs.yml) and the ApplyMIState typedef from pgindent's typedefs.list. Every INSERT now goes through the normal single-tuple apply path.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
💤 Files with no reviewable changes (10)
📝 WalkthroughWalkthroughThis change removes the batch insert feature from the codebase, including its configuration option ( Changes
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Duplication | 0 |
TIP This summary will be updated as you push new changes. Give us feedback
The batch-insert optimisation in the apply worker buffered consecutive inserts to the same relation and flushed them via
heap_multi_insert(), gated by thespock.batch_insertsGUC. The feature was silently disabled wheneveruse_try_blockwas active, and the code itself contained an acknowledged TODO noting uncertainty around snapshot push/pop semantics and command-counter visibility — a subsequent UPDATE or DELETE replicated in the same transaction could need to see those buffered tuples, with no clear guarantee that was correct.Given the correctness risk and the added complexity, the feature is removed entirely.
Changes
spock.batch_insertsGUC and itsspock_batch_insertsglobal variable (spock.c,spock.h).multi_insert_finish()and all six of its call sites fromspock_apply.c(at commit, relation-change, update, delete, and two points insidehandle_insert).ApplyMIStatestruct, thespkmistatestatic variable, and the entirespock_apply_heap_mi_*()function family (can_mi,mi_start,mi_flush,mi_add_tuple,mi_finish) fromspock_apply_heap.c/.h.docs/managing/batch_inserts.md(deleted), references indocs/configuring.md,docs/conflicts.md,docs/managing/index.md, andmkdocs.yml.ApplyMIStatetypedef fromutils/pgindent/typedefs.list.Every INSERT now goes through the normal single-tuple apply path.