Re: Fix premature xmin advancement during fast forward decoding
От | Amit Kapila |
---|---|
Тема | Re: Fix premature xmin advancement during fast forward decoding |
Дата | |
Msg-id | CAA4eK1+CmM-O17ryj7VaeS=d0gCKiAj6Np_3KQ8BAFoTS1s6Wg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix premature xmin advancement during fast forward decoding (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Fix premature xmin advancement during fast forward decoding
|
Список | 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.
В списке pgsql-hackers по дате отправления: