Re: Block-level CRC checks

Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> >Alvaro Herrera wrote:
> >
> > Hmm, oh I see another problem here -- the bit is not restored when
> > replayed heap_update's WAL record. I'm now wondering what other bits
> > are set without much care about correctly restoring them during replay.
> >
> > I'm now wondering whether it'd be easier to just ignore pd_flags in
> > calculating the checksum.
>
> Okay, so this is what I've done. pd_flags is skipped. Also the WAL
> routine logs both HeapTupleHeader infomasks and ItemId->lp_flags. On
> the latter point I'm not 100% sure of the cases where lp_flags must be
> logged; right now I'm only logging if the item is marked as "having
> storage" (the logic being that if an item does not have storage, then
> making it have requires a WAL entry, and vice versa).

Might it make sense to move such flags to another data structure which
may or may not need to be logged, thereby maintaining the crc integrity
of the data pages themselves?

(I pre-apologize if this is a silly, as I honestly don't understand how once
a page has been logically committed to storage, it can ever be subsequently
validly modified unless first removed as being committed to storage; as if
it's write were interrupted prior to being completed, it seems most correct
to simply consider the page as not having been stored and simply resume the
process from the beginning if a partial store is suspected; thereby implying
that any buffers storing the logical page are not released until the page as
a whole is known to have been successfully stored; thereby retaining the
entire page to either to remain committed for storage, or possibly
alternatively made re-available for mutation with it's crc marked as invalid
if ever mutated prior to being re-committed to storage, it seems.)