On Tue, Jul 19, 2022 at 7:28 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Tue, Jul 19, 2022 at 9:25 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Tue, Jul 19, 2022 at 1:10 PM Masahiko Sawada <sawada.m...@gmail.com> > > wrote: > > > > > > > > BTW on backbranches, I think that the reason why we add > > > initial_running_xacts stuff to ReorderBuffer is that we cannot modify > > > SnapBuild that could be serialized. Can we add a (private) array for > > > the initial running xacts in snapbuild.c instead of adding new > > > variables to ReorderBuffer? > > > > > > > While thinking about this, I wonder if the current patch for back > > branches can lead to an ABI break as it changes the exposed structure? > > If so, it may be another reason to change it to some other way > > probably as you are suggesting. > > Yeah, it changes the size of ReorderBuffer, which is not good. >
So, are you planning to give a try with your idea of making a private array for the initial running xacts? I am not sure but I guess you are proposing to add it in SnapBuild structure, if so, that seems safe as that structure is not exposed. > Changing the function names and arguments would also break ABI. So > probably we cannot do the above idea of removing > ReorderBufferInitialXactsSetCatalogChanges() as well. > Why do you think we can't remove ReorderBufferInitialXactsSetCatalogChanges() from the back branch patch? I think we don't need to change the existing function ReorderBufferXidHasCatalogChanges() but instead can have a wrapper like SnapBuildXidHasCatalogChanges() similar to master branch patch. -- With Regards, Amit Kapila.
