On Mon, Jul 20, 2020 at 4:30 PM Andres Freund <and...@anarazel.de> wrote: > I'm extremely doubtful this is a good idea. In all likelihood this will > just exascerbate corruption. > > You cannot just stop freezing tuples, that'll lead to relfrozenxid > getting *further* out of sync with the actual table contents. And you > cannot just freeze such tuples, because that has a good chance of making > deleted tuples suddenly visible, leading to unique constraint violations > etc. Which will then subsequently lead to clog lookup errors and such.
I think that the behavior ought to be: - If we encounter any damaged tuples (e.g. tuple xid < relfrozenxid), we give up on advancing relfrozenxid and relminmxid. This vacuum won't change them at all. - We do nothing to the damaged tuples themselves. - We can still prune pages, and we can still freeze tuples that do not appear to be damaged. This amounts to an assumption that relfrozenxid is probably sane, and that there are individual tuples that are messed up. It's probably not the right thing if relfrozenxid got overwritten with a nonsense value without changing the table contents. But, I think it's difficult to cater to all contingencies. In my experience, the normal problem here is that there are a few tuples or pages in the table that somehow escaped vacuuming for long enough that they contain references to XIDs from before the last time relfrozenxid was advanced - so continuing to do what we can to the rest of the table is the right thing to do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
