Re: BLK_DONE state in XLogReadBufferForRedoExtended

On Mon, Oct 16, 2017 at 9:50 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> If above analysis is correct, then I think we can say that row state
> in a page will be same during recovery as it was when the original
> operation was performed if the full_page_writes are enabled. I am not
> sure how much this can help in current heap format, but this can help
> in zheap (undo based heap).

If I understood that correctly, that looks like a sane assumption. For
REGBUF_NO_IMAGE you may need to be careful though with undo
operations.

> In zheap, we are writing complete tuple for Delete operation in undo
> so that we can reclaim the corresponding tuple space as soon as the
> deleting transaction is committed. Now, during recovery, we have to
> generate the complete undo record (which includes the entire tuple)
> and for that ideally, we should write the complete tuple in WAL, but
> instead of that, I think we can regenerate it from the original page.
> This is only applicable when full_page_writes are enabled, otherwise,
> a complete tuple is required in WAL.

Yeah, you should really try to support both modes as well.
Fortunately, it is possible to know if full page writes are enforced
at the moment a record is assembled and inserted, so you could rely on
that.

> I am not sure how much above makes sense to anyone without a detailed
> explanation, but I thought I should give some background on why I
> asked this question. However, if anybody needs more explanation or
> sees any fault in above understanding, please let me know.

Thanks for clarifying, I was wondering the reason behind the question
as well. It is the second time that I see the word zheap on -hackers,
and the first time was no longer than 2 days ago by Robert.
--
Michael