From: Masahiko Sawada <masahiko.saw...@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 impractical performance 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
