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? 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? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
