Re: Error "initial slot snapshot too large" in create replication slot

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.

(The title of the patch was changed accordingly.)

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center