MIME-Version: 1.0
References: <OS0PR01MB57163087F86621D44D9A72BF94BB2@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <CAD21AoD1_-ypJg7e0WEqDyCGBgOhH8ka3M1nPj1Dk=ADG44+GQ@mail.gmail.com>
 <OS0PR01MB57164FB1294A5CBE590097EE94842@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <CAA4eK1+pWwcbhJMm-VBugavEvhMGTwx7eD4MZ5nhND1YOp17Cg@mail.gmail.com>
 <CAD21AoBw_DX3L5mBN3kryc0mZ1TzbT-GFhWPjLubKAHRtVh-bg@mail.gmail.com>
 <CAA4eK1+CmM-O17ryj7VaeS=d0gCKiAj6Np_3KQ8BAFoTS1s6Wg@mail.gmail.com> <CAD21AoBY7KoiJZW-dOoMoS0WwBtDfw_g+5rw1DoyqhoJc7nuWA@mail.gmail.com>
In-Reply-To: <CAD21AoBY7KoiJZW-dOoMoS0WwBtDfw_g+5rw1DoyqhoJc7nuWA@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Sat, 26 Apr 2025 17:31:29 +0530
Message-ID: <CAA4eK1Kp0qopesYYQ0OvH4+1UZ4XBVKiNkMGtgk80SCmcfkYhQ@mail.gmail.com>
Subject: Re: Fix premature xmin advancement during fast forward decoding
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shveta.malik@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1Kp0qopesYYQ0OvH4%2B1UZ4XBVKiNkMGtgk80SCmcfkYhQ%40mail.gmail.com>
Precedence: bulk

On Sat, Apr 26, 2025 at 12:01=E2=80=AFAM Masahiko Sawada <sawada.mshk@gmail=
.com> wrote:
>
> On Fri, Apr 25, 2025 at 4:42=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.=
com> wrote:
> >
> > On Fri, Apr 25, 2025 at 10:46=E2=80=AFAM Masahiko Sawada <sawada.mshk@g=
mail.com> wrote:
> > >
> > > What I'm concerned about is the back branches. With this approach all
> > > back branches will have such degradations and it doesn't make sense t=
o
> > > me to optimize SnapBuildCommitTxn() codes in back branches.
> > >
> >
> > One possibility could be that instead of maintaining an entire
> > snapshot in fast_forward mode, we can maintain snapshot's xmin in each
> > ReorderBufferTXN. But then also, how would we get the minimum
> > txns_by_base_snapshot_lsn as we are getting now in
> > ReorderBufferGetOldestXmin? I think we need to traverse the entire
> > list of txns to get it in fast_forward mode but that may not show up
> > because it will not be done for each transaction. We can try such a
> > thing, but it won't be clean to have fast_forward specific code and
> > also it would be better to add such things only for HEAD.
>
> Agreed.
>

We may need to consider handling xmin in SnapBuildCommitTxn(), where
we also set the base snapshot.

> > Can you think of any better ideas?
>
> No idea. Hmm, there seems no reasonable way to fix this issue for back
> branches. I consented to the view that these costs were something that
> we should have paid from the beginning.
>

Right, I feel we should go with the simple change proposed by Hou-San
for now to fix the bug. If, in the future, we encounter any cases
where such optimizations can help for fast-forward mode, then we can
consider it. Does that sound reasonable to you?

--=20
With Regards,
Amit Kapila.