Re: Transactions involving multiple postgres foreign servers, take 2

At Wed, 14 Oct 2020 12:09:34 +0900, Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote in 
> On Wed, 14 Oct 2020 at 10:16, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrot> > There are cases of commit-failure
ofa local transaction caused by
 
> > too-many notifications or by serialization failure.
> 
> Yes, even if that happens we are still able to rollback all foreign
> transactions.

Mmm. I'm confused. If this is about 2pc-commit-request(or prepare)
phase, we can rollback the remote transactions. But I think we're
focusing 2pc-commit phase. remote transaction that has already
2pc-committed, they can be no longer rollback'ed.

> > > to commit the local transaction without preparation, the local
> > > transaction must be committed at last. But since the above sequence
> > > doesn’t follow this protocol, we will have such problems. I think if
> > > we follow the 2pc properly, such basic failures don't happen.
> >
> > True. But I haven't suggested that sequence.
> 
> Okay, I might have missed your point. Could you elaborate on the idea
> you mentioned before, "I think remote-commits should be performed
> before local commit passes the point-of-no-return"?

It is simply the condition that we can ERROR-out from
CommitTransaction. I thought that when you say like "we cannot
ERROR-out" you meant "since that is raised to FATAL", but it seems to
me that both of you are looking another aspect.

If the aspect is "what to do complete the all-prepared p2c transaction
at all costs", I'd say "there's a fundamental limitaion".  Although
I'm not sure what you mean exactly by prohibiting errors from fdw
routines , if that meant "the API can fail, but must not raise an
exception", that policy is enforced by setting a critical
section. However, if it were "the API mustn't fail", that cannot be
realized, I believe.

> > I thought that we are discussing on fdw-errors during the 2pc-commit
> > phase.
> >
> 
> Yes, I'm also discussing on fdw-errors during the 2pc-commit phase
> that happens after committing the local transaction.
> 
> Even if FDW-commit raises an error due to the user's cancel request or
> whatever reason during committing the prepared foreign transactions,
> it's too late. The client will get an error like "ERROR:  canceling
> statement due to user request" and would think the transaction is
> aborted but it's not true, the local transaction is already committed.

By the way I found that I misread the patch. in v26-0002,
AtEOXact_FdwXact() is actually called after the
point-of-no-return. What is the reason for the place?  We can
error-out before changing the state to TRANS_COMMIT.

And if any of the remotes ended with 2pc-commit (not prepare phase)
failure, consistency of the commit is no longer guaranteed so we have
no choice other than shutting down the server, or continuing running
allowing the incosistency.  What do we want in that case?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center