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

On Tue, Sep 13, 2022 at 11:52 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> Thanks for raizing this up, Robert and the comment, Andres.
>
> At Tue, 13 Sep 2022 07:00:42 +0530, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote in
> > On Tue, Sep 13, 2022 at 3:22 AM Andres Freund <andres(at)anarazel(dot)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