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

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 wonder if a better fix here wouldn't be to allow importing a snapshot with a
> > larger ->xid array. Yes, we can't do that in CurrentSnapshotData, but IIRC we
> > need to be in a transactional snapshot anyway, which is copied anyway?
>
> Yeah when I first found this issue, I thought that should be the
> solution. But later it went in a different direction.

I think that that is the best solution if rbtxn_is_known_subxzact() is
known to be unreliable at the time.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center