On Fri, Aug 28, 2020 at 1:29 PM Andres Freund <and...@anarazel.de> wrote: > It can break HOT chains, plain ctid chains etc, for example. Which, if > earlier / follower tuples are removed can't be detected anymore at a > later time.
I think I need a more specific example here to understand the problem. If the xmax of one tuple matches the xmin of the next, then either both values precede relfrozenxid or both follow it. In the former case, neither tuple should be frozen and the chain should not get broken; in the latter case, everything's normal anyway. If the xmax and xmin don't match, then the chain was already broken. Perhaps we are removing important evidence, though it seems like that might've happened anyway prior to reaching the damaged page, but we're not making whatever corruption may exist any worse. At least, not as far as I can see. > And we've had many long > standing bugs in this area, several only found because we actually > started to bleat about them. And quite evidently, we have more bugs to > fix in the area. I agree with all of this, but I do not think that it establishes that we should abandon the entire VACUUM. "Bleating" about something usually means logging it, and I think you understand that I am not now nor have I ever complained about the logging we are doing here. I also think you understand why I don't like the current behavior, and that EDB has actual customers who have actually been damaged by it. All the same, I don't expect to win an argument about changing the default, but I hope to win one about at least providing an option. And if we're not even going to do that much, then I hope to come out of this discussion with a clear understanding of exactly why that's a bad idea. I don't think "we need the data for forensics" is a sufficient justification for "if you end up with one corrupted XID in a billion-row table, your entire table will bloat out the wazoo, and there is no option to get any other behavior." -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
