On Mon, Aug 5, 2019 at 6:29 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Aug 5, 2019 at 6:16 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > For zheap, we collect all the records of a page, apply them together
> > and then write the entire page in WAL. The progress of transaction is
> > updated at either transaction end (rollback complete) or after
> > processing some threshold of undo records. So, generally, the WAL
> > won't be for each undo record apply.
>
> This explanation omits a crucial piece of the mechanism, because
> Heikki is asking what keeps the undo from being applied multiple
> times.
>
Okay, I didn't realize that.
> When we apply the undo records to a page, we also adjust the
> undo pointers in the page. Since we have an undo pointer per
> transaction slot, and each transaction has its own slot, if we apply
> all the undo for a transaction to a page, we can just clear the slot;
> if we somehow end up back at the same point later, we'll know not to
> apply the undo a second time because we'll see that there's no
> transaction slot pointing to the undo we were thinking of applying. If
> we roll back to a savepoint, or for some other reason choose to apply
> only some of the undo to a page, we can set the undo record pointer
> for the transaction back to the value it had before we generated any
> newer undo. Then, we'll know that the newer undo doesn't need to be
> applied but the older undo can be applied.
>
> At least, I think that's how it's supposed to work.
>
Right, this is how it works.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
