From: Masahiko Sawada <sawada.m...@gmail.com> > Maybe it's better to start a new thread to discuss this topic. If your > idea is good, we can lower all error that happened after writing the > commit record to warning, reducing the cases where the client gets > confusion by receiving an error after the commit.
No. It's an important part because it determines the 2PC behavior and performance. This discussion had started from the concern about performance before Ikeda-san reported pathological results. Don't rush forward, hoping someone will commit the current patch. I'm afraid you just don't want to change your design and code. Let's face the real issue. As I said before, and as Ikeda-san's performance benchmark results show, I have to say the design isn't done sufficiently. I talked with Fujii-san the other day about this patch. The patch is already huge and it's difficult to decode how the patch works, e.g., what kind of new WALs it emits, how many disk writes it adds, how the error is handled, whether/how it's different from the textbook or other existing designs, etc. What happend to my request to add such design description to the following page, so that reviewers can consider the design before spending much time on looking at the code? What's the situation of the new FDW API that should naturally accommodate other FDW implementations? Atomic Commit of Distributed Transactions https://wiki.postgresql.org/wiki/Atomic_Commit_of_Distributed_Transactions Design should come first. I don't think it's a sincere attitude to require reviewers to spend long time to read the design from huge code. Regards Takayuki Tsunakawa
