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
