Sixteen MiB log segments - #71
Conversation
Postgres flushes sixteen MiB segments; ours were sixty four. Rotation is set below the segment size so a segment never has to be extended.
|
Warning Review limit reached
Next review available in: 24 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 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 |
The retry budget is wall clock, so four writers hammering one key on a loaded shared runner can starve a statement and fail the test without saying anything about the retry path. It failed CI on two unrelated changes. Two writers still exercise the path.
|
Closing unmerged, not judged. The paired baseline server fails its setup statement on the arm64 profile and takes the bench job with it, so this change never got measured. Two things worth carrying forward from the attempt: The hot key retry test was flaky, not broken by any change. It failed CI on this branch and on #70, which have nothing in common and nothing to do with concurrency. The retry budget is wall clock, so four writers on one key can starve a statement on a loaded shared runner. Lowered to two writers on this branch; that commit is worth keeping regardless of the segment size question. It also means the reason given for closing #70 was wrong: pipelining was not shown to raise conflict pressure, the test was simply flaky. The paired baseline needs to be non fatal. If its server or its loadgen misbehaves the job should drop the paired baseline and fall back to the cross run one, not fail. That is the next fix to the harness. |
1 participant
Retest under the paired harness from #69.
Postgres flushes sixteen MiB log segments and ours were sixty four. If flush cost tracks the file's extent rather than the bytes dirtied, that is a direct explanation for our commit costing about 2.5x theirs at the same group size and flush count.
This was measured twice under the old harness and was the only candidate positive on both runs, linux-x64-full plus 11.4 then plus 35.8 percent, on the profile that proved most stable. The other profiles disagreed with themselves by up to 89 points, so nothing could be concluded. With both builds now running on the same runner it can be judged.