Re: Tablesync early exit

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.

Anyway, it seems there is no chance of this getting committed, so it
is time for me to stop flogging this dead horse.

I will remove this from the CF.

------
Kind Regards,
Peter Smith
Fujitsu Australia