On Wed, Apr 20, 2022 at 6:13 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Apr 20, 2022 at 2:38 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Wed, Apr 20, 2022 at 12:51 PM Masahiko Sawada > <sawada.m...@gmail.com> wrote: > > > > > > On Wed, Apr 20, 2022 at 11:46 AM wangw.f...@fujitsu.com > > > <wangw.f...@fujitsu.com> wrote: > > > > ``` > > > > > > I'm concerned that this 4-byte padding at the end of the struct could > > > depend on platforms (there might be no padding in 32-bit platforms?). > > > > > > > Good point, but ... > > > > > It seems to me that it's better to put it after fast_forward where the > > > new field should fall within the padding space. > > > > > > > Can we add the variable in between the existing variables in the > > structure in the back branches? > > > > I think it should be fine if it falls in the padding space. We have > done similar changes recently in back-branches [1]. I think it would > be then better to have it in the same place in HEAD as well? > > [1] - > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=10520f4346 > 876aad4941797c2255a21bdac74739 Thanks for your comments.
The comments by Sawada-San sound reasonable to me. After doing check, I found that padding in HEAD is the same as in REL14. So I change the approach of patch for HEAD just like the patch for REL14. On Wed, Apr 20, 2022 at 3:21 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > I'm concerned that this 4-byte padding at the end of the struct could > depend on platforms (there might be no padding in 32-bit platforms?). > It seems to me that it's better to put it after fast_forward where the > new field should fall within the padding space. Fixed. Add new variable after fast_forward. > BTW the changes in > REL_14_v1-0001-Fix-the-logical-replication-timeout-during-large-.patch, > adding end_xact to LogicalDecodingContext, seems good to me and it > might be better than the approach of v17 patch from plugin developers’ > perspective? This is because they won’t need to pass true/false to > end_xact of OutputPluginUpdateProgress(). Furthermore, if we do what > we do in update_replication_progress() in > OutputPluginUpdateProgress(), what plugins need to do will be just to > call OutputPluginUpdate() in every callback and they don't need to > have the CHANGES_THRESHOLD logic. What do you think? Change the approach of patch for HEAD. (The size of structure does not change.) Also move the logical of function update_replication_progress to function OutputPluginUpdateProgress. Attach the patches. [suggestion by Sawada-San] 1. Change the position of the new variable in structure. 2. Change the approach of the patch for HEAD. 3. Delete the new function update_replication_progress. Regards, Wang wei
HEAD_v18-0001-Fix-the-logical-replication-timeout-during-large.patch
Description: HEAD_v18-0001-Fix-the-logical-replication-timeout-during-large.patch
REL14_v2-0001-Fix-the-logical-replication-timeout-during-large-.patch
Description: REL14_v2-0001-Fix-the-logical-replication-timeout-during-large-.patch
