RE: Transactions involving multiple postgres foreign servers, take 2

From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
> > Unfortunately, I'm afraid we can do nothing about it.  If the DBMS's client
> library doesn't support cancellation (e.g. doesn't respond to Ctrl+C or provide a
> function that cancel processing in pgorogss), then the Postgres user just finds
> that he can't cancel queries (just like we experienced with odbc_fdw.)
> 
> So the idea of using another process to commit prepared foreign
> transactions seems better also in terms of this point. Even if a DBMS
> client library doesn’t support query cancellation, the transaction
> commit can return the control to the client when the user press ctl-c
> as the backend process is just sleeping using WaitLatch() (it’s
> similar to synchronous replication)

I have to say that's nitpicking.  I believe almost nobody does, or cares about, canceling commits, at the expense of
impracticalperformance due to non-parallelism, serial execution in each resolver,  and context switches.
 

Also, FDW is not cancellable in general.  It makes no sense to care only about commit.

(Fortunately, postgres_fdw is cancellable in any way.)


Regards
Takayuki Tsunakawa