On Tue, Sep 13, 2022 at 11:52 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > Thanks for raizing this up, Robert and the comment, Andres. > > At Tue, 13 Sep 2022 07:00:42 +0530, Dilip Kumar <dilipbal...@gmail.com> wrote > in > > On Tue, Sep 13, 2022 at 3:22 AM Andres Freund <and...@anarazel.de> wrote: > > > > > > > > It's not obvious to me that it's the right design (or even correct) to ask > > > reorderbuffer about an xid being a subxid. Maybe I'm missing something, > > > but > > > why would reorderbuffer even be guaranteed to know about all these > > > subxids? > > > > Yeah, you are right, the reorderbuffer will only know about the > > transaction for which changes got added to the reorder buffer. So > > this seems not to be the right design idea. > > That function is called after the SnapBuild reaches > SNAPBUILD_CONSISTENT state ,or SnapBuildInitialSnapshot() rejects > other than that state. That is, IIUC the top-sub relationship of all > the currently running transactions is fully known to reorder buffer. > We need a comment about that.
I don't think this assumption is true, any xid started after switching to the SNAPBUILD_FULL_SNAPSHOT and before switching to the SNAPBUILD_CONSISTENT, might still be in progress so we can not identify whether they are subxact or not from reorder buffer. refer to this comment: /* * c) transition from FULL_SNAPSHOT to CONSISTENT. * * In FULL_SNAPSHOT state (see d) ), and this xl_running_xacts' * oldestRunningXid is >= than nextXid from when we switched to * FULL_SNAPSHOT. This means all transactions that are currently in * progress have a catalog snapshot, and all their changes have been * collected. Switch to CONSISTENT. */ -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
