On Mon, Oct 24, 2022 at 7:56 AM Peter Geoghegan <pg@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
