RE: Transactions involving multiple postgres foreign servers, take 2

From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
> So what's your opinion?

My opinion is simple and has not changed.  Let's clarify and refine the design first in the following areas (others may
havepointed out something else too, but I don't remember), before going deeper into the code review.
 

* FDW interface
New functions so that other FDWs can really implement.  Currently, XA seems to be the only model we can rely on to
validatethe FDW interface.
 
What FDW function would call what XA function(s)?  What should be the arguments for the FEW functions?

* Performance
Parallel prepare and commits on the client backend.  The current implementation is untolerable and should not be the
firstrelease quality.  I proposed the idea.
 
(If you insist you don't want to anything about this, I have to think you're just rushing for the patch commit.  I want
tokeep Postgres's reputation.)
 
As part of this, I'd like to see the 2PC's message flow and disk writes (via email and/or on the following wiki.)  That
helpsevaluate the 2PC performance, because it's hard to figure it out in the code of a large patch set.  I'm simply
imaginingwhat is typically written in database textbooks and research papers.  I'm asking this because I saw some
discussionin this thread that some new WAL records are added.  I was worried that transactions have to write WAL
recordsother than prepare and commit unlike textbook implementations.
 

Atomic Commit of Distributed Transactions
https://wiki.postgresql.org/wiki/Atomic_Commit_of_Distributed_Transactions

* Query cancellation
As you showed, there's no problem with postgres_fdw?
The cancelability of FDW in general remains a problem, but that can be a separate undertaking.

* Global visibility
This is what Amit-san suggested some times -- "design it before reviewing the current patch."  I'm a bit optimistic
aboutthis and think this FDW 2PC can be implemented separately as a pure enhancement of FDW.  But I also understand his
concern. If your (our?) aim is to use this FDW 2PC for sharding, we may have to design the combination of 2PC and
visibilityfirst.
 



> I don’t think we need to stipulate the query cancellation. Anyway I
> guess the facts neither that we don’t stipulate anything about query
> cancellation now nor that postgres_fdw might not be cancellable in
> some situations now are not a reason for not supporting query
> cancellation. If it's a desirable behavior and users want it, we need
> to put an effort to support it as much as possible like we’ve done in
> postgres_fdw.  Some FDWs unfortunately might not be able to support it
> only by their functionality but it would be good if we can achieve
> that by combination of PostgreSQL and FDW plugins.

Let me comment on this a bit; this is a bit dangerous idea, I'm afraid.  We need to pay attention to the FDW interface
andits documentation so that FDW developers can implement what we consider important -- query cancellation in your
discussion. "postgres_fdw is OK, so the interface is good" can create interfaces that other FDW developers can't use.
That'swhat Tomas Vondra pointed out several years ago.
 


Regards
Takayuki Tsunakawa