On Thu, Nov 3, 2016 at 12:34 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Nov 3, 2016 at 3:24 PM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> > wrote: >> On Thu, Nov 3, 2016 at 2:35 AM, Michael Paquier >>> - /* If it's a full-page image, restore it. */ >>> - if (XLogRecHasBlockImage(record, block_id)) >>> + /* If full-page image should be restored, do it. */ >>> + if (XLogRecBlockImageApply(record, block_id)) >>> Hm. It seems to me that this modification is incorrect. If the page >>> does not need to be applied, aka if it needs to be used for >>> consistency checks, what should be done is more something like the >>> following in XLogReadBufferForRedoExtended: >>> if (Apply(record, block_id)) >>> return; >>> if (HasImage) >>> { >>> //do what needs to be done with an image >>> } >>> else >>> { >>> //do default things >>> } >>> >> XLogReadBufferForRedoExtended should return a redo action >> (block restored, done, block needs redo or block not found). So, we >> can't just return >> from the function if BLKIMAGE_APPLY flag is not set. It still has to >> check whether a >> redo is required or not. > > Wouldn't the definition of a new redo action make sense then? Say > SKIPPED. None of the existing actions match the non-apply case.
As per my understanding, XLogReadBufferForRedoExtended works as follows: 1. If wal record has backup block 2. { 3. restore the backup block; 4. return BLK_RESTORED; 5. } 6. else 7. { 8. If block found in buffer 10. If lsn of block is less than last replayed record 11. return BLK_DONE; 12. else 13. return BLK_NEEDS_REDO; 14. else 15. return BLK_NOT_FOUND; 16. } Now, we can just change step 1 as follows: 1. If wal record has backup block and it needs to be restored. I'm not getting why we should introduce a new redo action and return from the function beforehand. -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers