+ * changed to "inprogress-off", the barrier for mvoving to "off" can be
moving
+ * When disabling checksums, data_checksums will be set of "inprogress-off"
set *to*
+ get_namespace_name(RelationGetNamespace(reln)),
RelationGetRelationName(reln),
I think this palloc()s a new copy of the namespace every 100 blocks.
Better do it outside the loop.
+ {"inprogress-on", DATA_CHECKSUMS_INPROGRESS_ON, true},
+ {"inprogress-off", DATA_CHECKSUMS_INPROGRESS_OFF, true},
enabling / disabling ?
+typedef enum ChecksumType
+{
+ DATA_CHECKSUMS_OFF = 0,
+ DATA_CHECKSUMS_ON,
+ DATA_CHECKSUMS_INPROGRESS_ON,
+ DATA_CHECKSUMS_INPROGRESS_OFF
+} ChecksumType;
Should this be an bitmask, maybe
DATA_CHECKSUMS_WRITE = 1
DATA_CHECKSUMS_VERIFY = 2,
It occured to me that you could rephrase this patch as "Make checksum state
per-relation rather than cluster granularity". That's currently an
implementation detail, but could be exposed as a feature. That could be a
preliminary 0001 patch. Half the existing patch would be 0002 "Allow
online enabling checksums for a given relation/database/cluster". You might
save some of the existing effort of synchronize the cluster-wide checksum
state, since it doesn't need to be synchronized. The "data_checksums" GUC
might be removed, or changed to an enum: on/off/per_relation. Moving from
"per_relation" to "on" would be an optional metadata-only change, allowed only
when all rels in all dbs are checksumed. I'm not sure if you'd even care about
temp tables, since "relhaschecksum" would be authoritative, rather than a
secondary bit only used during processing.
XLogHintBitIsNeeded() and DataChecksumsEnabled() would need to check
relhaschecksum, which tentatively seems possible.
I'm not sure if it's possible, but maybe pg_checksums would be able to skip
rels which had already been checksummed "online" (with an option to force
reprocessing).
Maybe some people would want (no) checksums on specific tables, and that could
eventually be implemented as 0003: "ALTER TABLE SET checksums=". I'm thinking
of that being used immediately after an CREATE, but I suppose ON would cause
the backend to rewrite the table with checksums synchronously (not in the BGW),
either with AEL or by calling ProcessSingleRelationByOid().
--
Justin
