Re: Tablesync early exit

On Tue, Apr 5, 2022 at 9:37 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Sat, Apr 2, 2022 at 5:17 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Apr 1, 2022 at 1:52 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> > >
> > > On Wed, Mar 16, 2022 at 4:07 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > I think the STATE_CATCHUP guarantees the apply worker must have
> > > received (or tried to receive) a message. See the previous answer.
> > >
> >
> > Sorry, I intend to say till the sync worker has received any message.
> > The point is that LSN till where the copy has finished might actually
> > be later than some of the in-progress transactions on the server. It
> > may not be a good idea to blindly skip those changes if the apply
> > worker has already received those changes (say via a 'streaming'
> > mode). Today, all such changes would be written to the file and
> > applied at commit time but tomorrow, we can have an implementation
> > where we can apply such changes (via some background worker) by
> > skipping changes related to the table for which the table-sync worker
> > is in-progress. Now, in such a scenario, unless, we allow the table
> > sync worker to process more messages, we will end up losing some
> > changes for that particular table.
> >
> > As per my understanding, this is safe as per the current code but it
> > can't be guaranteed for future implementations and the amount of extra
> > work is additional work to receive the messages for one transaction. I
> > still don't think that it is a good idea to pursue this patch.
>
> IIUC you are saying that my patch is good today, but it may cause
> problems in a hypothetical future if the rest of the replication logic
> is implemented differently.
>

The approach I have alluded to above is already proposed earlier on
-hackers [1] to make streaming transactions perform better. So, it is
not completely hypothetical.

[1] - https://www.postgresql.org/message-id/8eda5118-2dd0-79a1-4fe9-eec7e334de17%40postgrespro.ru

--
With Regards,
Amit Kapila.