On Fri, May 12, 2023 at 12:48 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> > > 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.
What I was thinking of is that we implement non-delay cases (only for
streamed transactions) and then extend it to delay cases (i.e. adding
non-streamed transaction support and the delay mechanism). It might be
helpful if this patch becomes large and this approach can enable us to
reduce the complexity or divide the patch. That being said, I've not
considered this approach enough yet and it's just an idea. Extending
this feature to non-delay cases later also makes sense to me.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
