Date: Tue, 13 Sep 2022 15:22:37 +0900 (JST)
Message-Id: <20220913.152237.338218493796303493.horikyota.ntt@gmail.com>
To: dilipbalaut@gmail.com
Cc: andres@anarazel.de, jchampion@timescale.com, y.sokolov@postgrespro.ru,
 rjuju123@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Error "initial slot snapshot too large" in create replication
 slot
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: 
 <CAFiTN-sSbpHAvDg7gyaN5J2aaYEF4ycaSEAz0qfUJD_gM7n-eA@mail.gmail.com>
References: <20220719.115506.1518451006264600540.horikyota.ntt@gmail.com>
	<20220912215156.zi52zu6n7od3k3v3@awork3.anarazel.de>
	<CAFiTN-sSbpHAvDg7gyaN5J2aaYEF4ycaSEAz0qfUJD_gM7n-eA@mail.gmail.com>
User-Agent: Mew version 6.8 on Emacs 26.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20220913.152237.338218493796303493.horikyota.ntt%40gmail.com>
Precedence: bulk

Thanks for raizing this up, Robert and the comment, Andres.

At Tue, 13 Sep 2022 07:00:42 +0530, Dilip Kumar <dilipbalaut@gmail.com> wrote in 
> On Tue, Sep 13, 2022 at 3:22 AM Andres Freund <andres@anarazel.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