On Thu, Mar 23, 2023 at 10:53 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Wed, 22 Mar 2023 14:27:40 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > At Mon, 20 Mar 2023 13:46:51 -0400, "Gregory Stark (as CFM)" <stark.cfm@gmail.com> wrote in
> > > Kyotoro Horiguchi, any chance you'll be able to work on this for this
> > > commitfest? If so shout (or anyone else is planning to push it over
> > > the line.... Andres?) otherwise I'll move it on to the next release.
> >
> > Ugg. sorry for being lazy. I have lost track of the conversation. I'm
> > currently working on this and will come back soon with a new version.
>
> I relized that attempting to make SnapshotData.xip expansible was
> making procarray.c and snapmgr.c too complicated. The main reason is
> that SnapShotData is allocated in various ways, like on the stack,
> using palloc including xip/subxip arrays, with palloc then allocating
> xip/subxip arrays separately, or statically allocated and then having
> xip/subxip arrays malloc'ed later. This variety was making the
> expansion logic a mess.
>
> So I went back to square one and decided to use subxip as an extension
> for the xip array instead.
>
> Like the comment added in the function SnapBuildInitialSnapshot
> mentions, I don't think we can reliably identify top-level XIDs. So,
> this patch just increases the allowed number of XIDs by using the
> subxip array.
Thanks for working on this, your idea looks fine but my only worry is
that in the future if someone tries to change the logic of
XidInMVCCSnapshot() then they must be aware that the snap->xip array
and snap->subxip array no long distinguishes the top xids and subxids.
I agree with the current logic if we are not marking sub-overflow then
there is no issue, so can we document this in the SnapshotData
structure?
Also, there are some typos in the patch
/idetify/identify
/carete/create
/Aallocate/Allocate
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com