On Mon, 19 Oct 2020 at 14:39, tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com> wrote: > > 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,
Really? I don’t think so. I think It’s terrible that the query gets stuck for a long time and we cannot do anything than waiting until a crashed foreign server is restored. We can have a timeout but I don’t think every user wants to use the timeout or the user might want to set a timeout to a relatively large value by the concern of misdetection. I guess synchronous replication had similar concerns so it has a similar mechanism. > at the expense of impractical performance due to non-parallelism, serial > execution in each resolver, and context switches. I have never said that we’re going to live with serial execution in each resolver and non-parallelism. I've been repeatedly saying that it would be possible that we improve this feature over the releases to get a good performance even if we use a separate background process. Using a background process to commit is the only option to support interruptible foreign transaction resolution for now whereas there are some ideas for performance improvements. I think we don't have enough discussion on how we can improve the idea of using a separate process and how much performance will improve and how possible it is. It's not late to reject that idea after the discussion. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
