On Thu, Sep 10, 2020 at 4:20 PM Fujii Masao <masao.fu...@oss.nttdata.com> wrote: > > >> One alternative is to add only hooks into PostgreSQL core so that we can > >> implement the global transaction management outside. This idea was > >> discussed before as the title "eXtensible Transaction Manager API". > > > > Yeah, I read that discussion. And I remember Robert Haas and Postgres Pro > > people said it's not good... > > But it may be worth revisiting this idea if we cannot avoid the patent issue. >
It is not very clear what exactly we can do about the point raised by Tsunakawa-San related to patent in this technology as I haven't seen that discussed during other development but maybe we can try to study a bit. One more thing I would like to bring here is that it seems to be there have been some concerns about this idea when originally discussed [1]. It is not very clear to me if all the concerns are addressed or not. If one can summarize the concerns discussed and how the latest patch is able to address those then it will be great. Also, I am not sure but maybe global deadlock detection also needs to be considered as that also seems to be related because it depends on how we manage global transactions. We need to prevent deadlock among transaction operations spanned across multiple nodes. Say a transaction T-1 has updated row r-1 of tbl-1 on node-1 and tries to update row r-1 of tbl-2 on node n-2. Similarly, a transaction T-2 tries to perform those two operations in reverse order. Now, this will lead to the deadlock that spans across multiple nodes and our current deadlock detector doesn't have that capability. Having some form of global/distributed transaction id might help to resolve it but not sure how it can be solved with this clock-si based algorithm. As all these problems are related, that is why I am insisting on this thread and other thread "Transactions involving multiple postgres foreign servers" [2] to have a high-level idea on how the distributed transaction management will work before we decide on a particular approach and commit one part of that patch. [1] - https://www.postgresql.org/message-id/21BC916B-80A1-43BF-8650-3363CCDAE09C%40postgrespro.ru [2] - https://www.postgresql.org/message-id/CAA4eK1J86S%3DmeivVsH%2Boy%3DTwUC%2Byr9jj2VtmmqMfYRmgs2JzUA%40mail.gmail.com -- With Regards, Amit Kapila.
