On Mon, Jan 17, 2022 at 8:13 PM Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jan 17, 2022 at 5:41 PM Peter Geoghegan <p...@bowt.ie> wrote: > > That just seems like semantics to me. The very next sentence after the > > one you quoted in your reply was "And so it's highly unlikely that any > > given VACUUM will ever *completely* fail to advance relfrozenxid". > > It's continuous *within* each VACUUM. As far as I can tell there is > > pretty much no way that the patch series will ever fail to advance > > relfrozenxid *by at least a little bit*, barring pathological cases > > with cursors and whatnot. > > I mean this boils down to saying that VACUUM will advance relfrozenxid > except when it doesn't.
It actually doesn't boil down, at all. The world is complicated and messy, whether we like it or not. > > I never said that anti-wraparound vacuums just won't happen anymore. I > > said that they'll be limited to cases like the stock table or > > customers table case. I was very clear on that point. > > I don't know how I'm supposed to sensibly respond to a statement like > this. If you were very clear, then I'm being deliberately obtuse if I > fail to understand. I don't know if I'd accuse you of being obtuse, exactly. Mostly I just think it's strange that you don't seem to take what I say seriously when it cannot be proven very easily. I don't think that you intend this to be disrespectful, and I don't take it personally. I just don't understand it. > > It isn't that hard to see that the cases where we continue to get any > > anti-wraparound VACUUMs with the patch seem to be limited to cases > > like the stock/customers table, or cases like the pathological idle > > cursor cases we've been discussing. Pretty narrow cases, overall. > > Don't take my word for it - see for yourself. > > I don't think that's really possible. Words like "narrow" and > "pathological" are value judgments, not factual statements. If I do an > experiment where no wraparound autovacuums happen, as I'm sure I can, > then those are the normal cases where the patch helps. If I do an > experiment where they do happen, as I'm sure that I also can, you'll > probably say either that the case in question is like the > stock/customers table, or that it's pathological. What will any of > this prove? You seem to be suggesting that I used words like "pathological" in some kind of highly informal, totally subjective way, when I did no such thing. 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. 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. The claim that I have made is 100% testable. Even if it was flat out incorrect, not getting anti-wraparound VACUUMs per se is not the important part. The important part is that the work is managed intelligently, and the burden is spread out over time. I am particularly concerned about the "freezing cliff" we get when many pages are all-visible but not also all-frozen. Consistently avoiding an anti-wraparound VACUUM (except with very particular workload characteristics) is really just a side effect -- it's something that makes the overall benefit relatively obvious, and relatively easy to measure. I thought that you'd appreciate that. -- Peter Geoghegan
