Hi Greg, > so, hopefully I've delivered v7 with:
You did, and it's the real v7 this time. I ran the three checks I said I would, on master at 964d88fac46 (there is a rebase note at the end): test_fileops/t/017 passes on all three paths -- online ROLLBACK, abort redo on a standby, startup undo -- 12/12, and t/018 (rename) is 68/68. FileOpsRename is immediate-with-rollback as of 0005, which is what the harness expected. The logical-revert-worker path that 0005 also mentions isn't exercised by 017, so that one is still uncovered if you want to add it. Per-prefix: all 20 prefixes build without warnings and pass the core check plus their own tests. The three things I flagged on v4 are fixed -- test_fileops is registered from 0002, 0004 carries only recovery/071, and recovery/134 passes in 0006. The fsync repro from the v6 thread, v4 vs v7, same machine, on a quiet lane (median with bootstrap CI95, n=9; both are cassert builds, so these are ratios, not production absolutes): - ROLLBACK of 32,000 chmods: 23.3 s -> 49.6 ms. - startup undo, 32,000 in flight: 24.3 s -> 48 ms. - abort redo of 32,000 inverses (n=3): ~24.8 s -> ~0.06 s. That is roughly 470x, 500x and 400x, and the gap grows with N (46x at 200), which matches v4 doing one fsync per record and v7 batching them. One rebase note: the posted v7 doesn't apply on current master (26bd08f): 0002 conflicts in recovery/meson.build with 068c9aaec31 (the new t/060_multixact_crashed_updater.pl) and leaves a duplicate 060. It is a context conflict; I measured on 964d88fac46, where git am is clean. cfbot will need the rebase too. Regards, Manu
