Re: Fix premature xmin advancement during fast forward decoding
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
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>
Date: 2025-04-25T11:41:48Z
Lists: pgsql-hackers
On Fri, Apr 25, 2025 at 10:46 AM Masahiko Sawada <sawada.mshk@gmail.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 to > 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. Can you think of any better ideas? -- With Regards, Amit Kapila.
Commits
-
Fix xmin advancement during fast_forward decoding.
- d65485b02b1f 13.21 landed
- aaf9e95e8764 18.0 landed
- 36148b22ee09 17.5 landed
- 21a7caeeb948 16.9 landed
- f6429bd7db5e 15.13 landed
- 1f63b3626a52 14.18 landed
-
Fix "base" snapshot handling in logical decoding
- f49a80c481f7 11.0 cited