On Mon, Oct 24, 2022 at 7:56 AM Peter Geoghegan <p...@bowt.ie> wrote: > I don't understand what you mean. FreezeLimit *isn't* always exactly > 50 million XIDs before OldestXmin -- not anymore. In fact that's the > main benefit of this work (commit c3ffa731). That detail has changed > (and changed for the better). Though it will only be noticeable to > users when an old snapshot holds back OldestXmin by a significant > amount.
I meant that the new behavior will only have a noticeable impact when OldestXmin is significantly earlier than nextXID. Most of the time there won't be any old snapshots, which means that there will only be a negligible difference between OldestXmin and nextXID when things are operating normally (OldestXmin will still probably be a tiny bit earlier than nextXID, but not enough to matter). And so most of the time the difference between the old approach and the new approach will be completely negligible; 50 million XIDs is usually a huge number (it is usually far far larger than the difference between OldestXmin and nextXID). BTW, I have some sympathy for the argument that the WARNINGs that we have here may not be enough -- we only warn when the situation is already extremely serious. I just don't see any reason why that problem should be treated as a regression caused by commit c3ffa731. The WARNINGs may be inadequate, but that isn't new. -- Peter Geoghegan
