On Mon, 19 Oct 2020 at 14:39, tsunakawa.takay@fujitsu.com
<tsunakawa.takay@fujitsu.com> wrote:
>
> 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,
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