Re: Error "initial slot snapshot too large" in create replication slot - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Error "initial slot snapshot too large" in create replication slot
Date
Msg-id 20220913.161059.331955937797746838.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Error "initial slot snapshot too large" in create replication slot  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Error "initial slot snapshot too large" in create replication slot
List pgsql-hackers
At Tue, 13 Sep 2022 12:08:18 +0530, Dilip Kumar <dilipbalaut@gmail.com> wrote in 
> On Tue, Sep 13, 2022 at 11:52 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > 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.

Yeah, I misunderstood that the relationship is recorded earlier
(how?).  Thus it is not reliable in the first place.

I agree that the best way is oversized xip. 


By the way, I feel that "is >= than" is redundant or plain wrong..

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Do we need to pass down nonnullable_vars when reducing outer joins?
Next
From: Michael Paquier
Date:
Subject: Re: pg_basebackup's --gzip switch misbehaves