On Tue, Aug 9, 2022 at 9:46 PM Simon Riggs <simon.riggs@enterprisedb.com> wrote:
> Those calls are unaffected, i.e. they both still work.
>
> Right now, we register all subxids in subtrans. But not all xids are
> subxids, so in fact, subtrans has many "holes" in it, where if you
> look up the parent for an xid it will just return
> c. There is a protection against that causing a
> problem because if you call TransactionIdDidCommit/Abort you can get a
> WARNING, or if you call SubTransGetTopmostTransaction() you can get an
> ERROR, but it is possible if you do a lookup for an inappropriate xid.
> i.e. if you call TransactionIdDidCommit() without first calling
> TransactionIdIsInProgress() as you are supposed to do.
IIUC, if SubTransGetParent SubTransGetParent then
SubTransGetTopmostTransaction() loop will break and return the
previousxid. So if we pass any topxid to
SubTransGetTopmostTransaction() it will return back the same xid and
that's fine as next we are going to search in the snapshot->xip array.
But if we are calling this function with the subxid which might be
there in the snapshot->subxip array but if we are first calling
SubTransGetTopmostTransaction() then it will just return the same xid
if the parent is not set for it. And now if we search this in the
snapshot->xip array then we will get the wrong answer?
So I still think some adjustment is required in XidInMVCCSnapdhot()
such that we first search the snapshot->subxip array.
Am I still missing something?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com