On Tue, Aug 9, 2022 at 9:46 PM Simon Riggs <simon.ri...@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