On Tue, Jan 18, 2022 at 6:11 AM Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jan 18, 2022 at 12:14 AM Peter Geoghegan <p...@bowt.ie> wrote: > > I quite clearly said that you'll only get an anti-wraparound VACUUM > > with the patch applied when the only factor that *ever* causes *any* > > autovacuum worker to VACUUM the table (assuming the workload is > > stable) is the anti-wraparound/autovacuum_freeze_max_age cutoff. With > > a table like this, even increasing autovacuum_freeze_max_age to its > > absolute maximum of 2 billion would not make it any more likely that > > we'd get a non-aggressive VACUUM -- it would merely make the > > anti-wraparound VACUUMs less frequent. No big change should be > > expected with a table like that. > > Sure, I don't disagree with any of that. I don't see how I could. But > I don't see how it detracts from the points I was trying to make > either.
You said "...the reasoning that says - anti-wraparound vacuums just aren't going to happen any more - or - relfrozenxid will advance continuously seems like dangerous wishful thinking to me". You then proceeded to attack a straw man -- a view that I couldn't possibly hold. This certainly surprised me, because my actual claims seemed well within the bounds of what is possible, and in any case can be verified with a fairly modest effort. That's what I was reacting to -- it had nothing to do with any concerns you may have had. I wasn't thinking about long-idle cursors at all. I was defending myself, because I was put in a position where I had to defend myself. > > Also, since the patch is not magic, and doesn't even change the basic > > invariants for relfrozenxid, it's still true that any scenario in > > which it's fundamentally impossible for VACUUM to keep up will also > > have anti-wraparound VACUUMs. But that's the least of the user's > > trouble -- in the long run we're going to have the system refuse to > > allocate new XIDs with such a workload. > > Also true. But again, it's just about making sure that the patch > doesn't make other decisions that make things worse for people in that > situation. That's what I was expressing uncertainty about. I am not just trying to avoid making things worse when users are in this situation. I actually want to give users every chance to avoid being in this situation in the first place. In fact, almost everything I've said about this aspect of things was about improving things for these users. It was not about covering myself -- not at all. It would be easy for me to throw up my hands, and change nothing here (keep the behavior that makes FreezeLimit derived from the vacuum_freeze_min GUC), since it's all incidental to the main goals of this patch series. I still don't understand why you think that my idea (not yet implemented) of making FreezeLimit into a backstop (making it autovacuum_freeze_max_age/2 or something) and relying on the new "early freezing" criteria for almost everything is going to make the situation worse in this scenario with long idle cursors. It's intended to make it better. Why do you think that the current vacuum_freeze_min_age-based FreezeLimit isn't actually the main problem in these scenarios? I think that the way that that works right now (in particular during aggressive VACUUMs) is just an accident of history. It's all path dependence -- each incremental step may have made sense, but what we have now doesn't seem to. Waiting for a cleanup lock might feel like the diligent thing to do, but that doesn't make it so. My sense is that there are very few apps that are hopelessly incapable of advancing relfrozenxid from day one. I find it much easier to believe that users that had this experience got away with it for a very long time, until their luck ran out, somehow. I would like to minimize the chance of that ever happening, to the extent that that's possible within the confines of the basic heapam/vacuumlazy.c invariants. -- Peter Geoghegan
