On Tue, Sep 3, 2019 at 4:30 AM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > In the interest of moving things forward, how far are we from making > 0001 committable? If I understand correctly, the rest of this patchset > depends on https://commitfest.postgresql.org/24/944/ which seems to be > moving at a glacial pace (or, actually, slower, because glaciers do > move, which cannot be said of that other patch.) >
I am not sure if it is completely correct that the other part of the patch is dependent on that CF entry. I have studied both the threads (not every detail) and it seems to me it is dependent on one of the patches from that series which handles concurrent aborts. It is patch 0003-Gracefully-handle-concurrent-aborts-of-uncommitted-t.Jan4.patch from what the Nikhil has posted on that thread [1]. Am, I wrong? So IIUC, the problem of concurrent aborts is that if we allow catalog scans for in-progress transactions, then we might get wrong answers in cases where somebody has performed Alter-Abort-Alter which is clearly explained with an example in email [2]. To solve that problem Nikhil seems to have written a patch [1] which detects these concurrent aborts during a system table scan and then aborts the decoding of such a transaction. Now, the problem is that patch has written considering 2PC transactions and might not deal with all cases for in-progress transactions especially when sub-transactions are involved as alluded by Arseny Sher [3]. So, the problem seems to be for cases when some sub-transaction aborts, but the main transaction still continued and we try to decode it. Nikhil's patch won't be able to deal with it because I think it just checks top-level xid whereas for this we need to check all-subxids which I think is possible now as Tomas seems to have written WAL for each xid-assignment. It might or might not be the best solution to check the status of all-subxids, but I think first we need to agree that the problem is just for concurrent aborts and that we can solve it by using some part of the technology being developed as part of patch "Logical decoding of two-phase transactions" (https://commitfest.postgresql.org/24/944/) rather than the entire patchset. I hope I am not saying something very obvious here and it helps in moving this patch forward. Thoughts? [1] - https://www.postgresql.org/message-id/CAMGcDxcBmN6jNeQkgWddfhX8HbSjQpW%3DUo70iBY3P_EPdp%2BLTQ%40mail.gmail.com [2] - https://www.postgresql.org/message-id/EEBD82AA-61EE-46F4-845E-05B94168E8F2%40postgrespro.ru [3] - https://www.postgresql.org/message-id/87a7py4iwl.fsf%40ars-thinkpad -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
