On 2/19/17 11:02 AM, David Christensen wrote:
> My design notes for the patch were submitted to the list with little comment; see:
https://www.postgresql.org/message-id/1E6E64E9-634B-43F4-8AA2-CD85AD92D2F8%40endpoint.com
>
> I have since added the WAL logging of checksum states, however I’d be glad to take feedback on the other proposed
approaches(particularly the system catalog changes + the concept of a checksum cycle).]
A couple notes:
- AFAIK unlogged tables get checksummed today if checksums are enabled;
the same should hold true if someone enables checksums on the whole cluster.
- Shared relations should be handled as well; you don't mention them.
- If an entire cluster is going to be considered as checksummed, then
even databases that don't allow connections would need to get enabled.
I like the idea of revalidation, but I'd suggest leaving that off of the
first pass.
It might be easier on a first pass to look at supporting per-database
checksums (in this case, essentially treating shared catalogs as their
own database). All normal backends do per-database stuff (such as
setting current_database) during startup anyway. That doesn't really
help for things like recovery and replication though. :/ And there's
still the question of SLRUs (or are those not checksum'd today??).
BTW, it occurs to me that this is related to the problem we have with
trying to make changes that break page binary compatibility. If we had a
method for handling that it would probably be useful for enabling
checksums as well. You'd essentially treat an un-checksum'd page as if
it was an "old page version". The biggest problem there is dealing with
the potential that the new page needs to be larger than the old one was,
but maybe there's some useful progress to be had in this area before
tackling the "page too small" problem.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)