On Thu, Aug 22, 2019 at 7:34 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Aug 22, 2019 at 1:34 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > Yeah, we can handle the bulk fetch as you suggested and it will make
> > it a lot easier. But, currently while registering the undo request
> > (especially during the first pass) we need to compute the from_urecptr
> > and the to_urecptr. And, for computing the from_urecptr, we have the
> > end location of the transaction because we have the uur_next in the
> > transaction header and that will tell us the end of our transaction
> > but we still don't know the undo record pointer of the last record of
> > the transaction. As of know, we read previous 2 bytes from the end of
> > the transaction to know the length of the last record and from there
> > we can compute the undo record pointer of the last record and that is
> > our from_urecptr.=
>
> I don't understand this. If we're registering an undo request at "do"
> time, we don't need to compute the starting location; we can just
> remember the UndoRecPtr of the first record we inserted. If we're
> reregistering an undo request after a restart, we can (and, I think,
> should) work forward from the discard location rather than backward
> from the insert location.
Right, we work froward from the discard location. So after the
discard location, while traversing the undo log when we encounter an
aborted transaction we need to register its rollback request. And,
for doing that we need 1) start location of the first undo record . 2)
start location of the last undo record (last undo record pointer).
We already have 1). But we have to compute 2). For doing that if we
unpack the first undo record we will know the start of the next
transaction. From there if we read the last two bytes then that will
have the length of the last undo record of our transaction. So we can
compute 2) with below formula
start of the last undo record = start of the next transaction - length
of our transaction's last record.
Am I making sense here?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
