Thank you for looking this. At Wed, 3 Apr 2019 10:16:02 -0400, Robert Haas <robertmh...@gmail.com> wrote in <CA+TgmoYEST4xYaU10gM=XXeA-oxbFh=qSfy0X4PXDCWubcgj=g...@mail.gmail.com> > On Tue, Apr 2, 2019 at 6:54 AM Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > By using DELETE and INSERT records to implement an UPDATE, you lose the > > > ctid > > > chain and infomask bits that were present before crash recovery. If > > > that's > > > okay in these circumstances, please write a comment explaining why. > > > > Sounds reasonable. Added a comment. (Honestly I completely forgot > > about that.. Thanks!) (0006) > > If you haven't already, I think you should set up a master and a > standby and wal_consistency_checking=all and run tests of this feature > on the master and see if anything breaks on the master or the standby. > I'm not sure that emitting an insert or delete record is going to > reproduce the exact same state on the standby that exists on the > master.
All of this patch is for wal_level = minimal. Doesn't make changes in other cases. Updates are always replicated as XLOG_HEAP_(HOT_)UPDATE. Crash recovery cases involving log_insert or log_update are exercised by the TAP test. > + * Insert log record. Using delete or insert log loses HOT chain > + * information but that happens only when newbuf is different from > + * buffer, where HOT cannot happen. > > "HOT chain information" seems pretty vague. Thanks. Actually I was a bit uneasy with "information". Does the following make sense? > * Insert log record, using delete or insert instead of update log > * when only one of the two buffers needs WAL-logging. If this were a > * HOT-update, redoing the WAL record would result in a broken > * hot-chain. However, that never happens because updates complete on > * a single page always use log_update. regards. -- Kyotaro Horiguchi NTT Open Source Software Center