Re: Tablesync early exit

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.

--
With Regards,
Amit Kapila.