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.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
