Problem

Today, when an index build enters a bad spill/merge-spill pattern, the operator may only discover that the configured memory limit is too low after the build has already started. In related cases, this has been called out as a practical problem because the need to raise maxIndexBuildMemoryUsageMegabytes often only becomes obvious once index builds are already in progress, at which point recovery can require restarting the broader operation.

We also have evidence of index-build-related workflows getting stuck or making no visible progress during spill/merge phases, with raising maxIndexBuildMemoryUsageMegabytes used as a workaround to get the operation through.

The current gap is that changing maxIndexBuildMemoryUsageMegabytes at runtime does not help enough once a running build is already trapped in this pattern. We need a mechanism for the running build to observe a higher value and apply it at a safe transition point.

Proposal

If maxIndexBuildMemoryUsageMegabytes is increased while an index build is already running, the running build should re-read and apply the new value after a spill boundary.

Concretely, the proposed trigger point is:

• after a spill completes, or
• before beginning the next post-spill accumulation / sort cycle

This would let the build use the new memory limit for subsequent spill decisions and in-memory accumulation. A spill boundary seems like the safest place to apply the change because it is already a natural phase transition in the sorter/index-build flow