Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

On Tue, Jan 18, 2022 at 6:11 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jan 18, 2022 at 12:14 AM Peter Geoghegan <pg(at)bowt(dot)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