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
