On 2020-Jul-20, Andrey M. Borodin wrote: > I think the point here is to actually move relfrozenxid back. But the > mince can't be turned back. If CLOG is rotated - the table is > corrupted beyond easy repair.
Oh, I see. Hmm. Well, if you discover relfrozenxid that's newer and the pg_clog files are still there, then yeah it might make sense to move relfrozenxid back. But it seems difficult to do correctly ... you have to move datfrozenxid back too ... frankly, I'd rather not go there. > I'm not sure it's Dilip's case, but I'll try to describe what I was > encountering. > > We were observing this kind of corruption in three cases: > 1. With a bug in patched Linux kernel page cache we could loose FS page write I think I've seen this too. (Or possibly your #3, which from Postgres POV is the same thing -- a write was claimed done but actually not done.) > FWIW we coped with this by actively monitoring this kind of corruption > with this amcheck patch [0]. One can observe this lost page updates > cheaply in indexes and act on first sight of corruption: identify > source of the buggy behaviour. Right. I wish we had some way to better protect against this kind of problems, but I don't have any ideas. Some things can be protected against with checksums, but if you just lose a write, there's nothing to indicate that. We don't have a per-page write counter, or a central repository of per-page LSNs or checksums, and it seems very expensive to maintain such things. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
