RE: Conflict detection for update_deleted in logical replication

On Sun, May 25, 2025 at 4:36 PM Dilip Kumar wrote:

>
> On Sat, May 24, 2025 at 4:46 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> >
> > This sounds reasonable to me. Let us see what others think.
> >
>
> I was looking into the for getting the transaction status from
> publisher, what I would assume this patch should be doing is request
> the publisher status first time, and if some transactions are still in
> commit, then we need to wait for them to get completed. But in the
> current design its possible that while we are waiting for in-commit
> transactions to get committed the old running transaction might come
> in commit phase and then we wait for them again, is my understanding
> not correct?

Thanks for reviewing the patch. And yes, your understanding is correct.

>
> Maybe this is very corner case that there are thousands of old running
> transaction and everytime we request the status we find some
> transactions is in commit phase and the process keep running for long
> time until all the old running transaction eventually get committed.
>
> I am thinking can't we make it more deterministic such that when we
> get the status first time if we find some transactions that are in
> commit phase then we should just wait for those transaction to get
> committed? One idea is to get the list of xids in commit phase and
> next time when we get the list we can just compare and in next status
> if we don't get any xids in commit phase which were in commit phase
> during previous status then we are done. But not sure is this worth
> the complexity? Mabe not but shall we add some comment explaining the
> case and also explaining why this corner case is not harmful?

I also think it's not worth the complexity for this corner case which is
rare. So, I have added some comments in wait_for_publisher_status() to
mention the same.

Best Regards,
Hou zj