From: Masahiko Sawada <sawada.mshk@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
theconcern about performance before Ikeda-san reported pathological results. Don't rush forward, hoping someone will
committhe 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
decodehow 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
suchdesign description to the following page, so that reviewers can consider the design before spending much time on
lookingat 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
designfrom huge code.
Regards
Takayuki Tsunakawa