On Sun, May 25, 2025 at 4:36 PM Dilip Kumar wrote: > > On Sat, May 24, 2025 at 4:46 PM Amit Kapila <amit.kapil...@gmail.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
