Re: Transactions involving multiple postgres foreign servers, take 2

On Mon, 19 Oct 2020 at 14:39, tsunakawa(dot)takay(at)fujitsu(dot)com
<tsunakawa(dot)takay(at)fujitsu(dot)com> wrote:
>
> From: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)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