Dear Amit, Sawada-san, Thank you for replying!
> On Thu, May 11, 2023 at 2:04 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu) > > <kuroda.hay...@fujitsu.com> wrote: > > > > > > Dear hackers, > > > > > > I rebased and refined my PoC. Followings are the changes: > > > > > > > 1. Is my understanding correct that this patch creates the delay files > > for each transaction? If so, did you consider other approaches such as > > using one file to avoid creating many files? > > 2. For streaming transactions, first the changes are written in the > > temp file and then moved to the delay file. It seems like there is a > > double work. Is it possible to unify it such that when min_apply_delay > > is specified, we just use the delay file without sacrificing the > > advantages like stream sub-abort can truncate the changes? > > 3. Ideally, there shouldn't be a performance impact of this feature on > > regular transactions because the delay file is created only when > > min_apply_delay is active but better to do some testing of the same. > > > > In addition to the points Amit raised, if the 'required_schema' option > is specified in START_REPLICATION, the publisher sends schema > information for every change. I think it leads to significant > overhead. Did you consider alternative approaches such as sending the > schema information for every transaction or the subscriber requests > the publisher to send it? Thanks for giving your opinions. Except for suggestion 2, I have never considered. I will analyze them and share my opinion later. About 2, I chose the style in order to simplify the source code, but I'm now planning to follow suggestions. > > Overall, I think such an approach can address comments by Sawada-San > > [1] but not sure if Sawada-San or others have any better ideas to > > achieve this feature. It would be good to see what others think of > > this approach. > > > > I agree with this approach. > > When it comes to the idea of writing logical changes to permanent > files, I think it would also be a good idea (and perhaps could be a > building block of this feature) that we write streamed changes to a > permanent file so that the apply worker can retry to apply them > without retrieving the same changes again from the publisher. I'm very relieved to hear that. One question: did you mean to say that serializing changes into the permanent files can be extend to the non-delay case, right? I think once I will treat for delayed replication, and then we can consider later. Best Regards, Hayato Kuroda FUJITSU LIMITED