RE: Transactions involving multiple postgres foreign servers, take 2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
> On Tue, Jun 15, 2021 at 5:51 AM tsunakawa(dot)takay(at)fujitsu(dot)com
> <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote:
> > Postgres can do that, but other implementations can not necessaily do it, I'm
> afraid. But before that, the FDW interface documentation doesn't describe
> anything about how to handle interrupts. Actually, odbc_fdw and possibly
> other FDWs don't respond to interrupts.
>
> Well, I'd consider that a bug.

I kind of hesitate to call it a bug... Unlike libpq, JDBC (for jdbc_fdw) doesn't have asynchronous interface, and Oracle and PostgreSQL ODBC drivers don't support asynchronous interface. Even with libpq, COMMIT (and other SQL commands) is not always cancellable, e.g., when the (NFS) storage server gets hand while writing WAL.

> > What we're talking here is mainly whether commit should return success or
> failure when some participants failed to commit in the second phase of 2PC.
> That's new to Postgres, isn't it? Anyway, we should respect existing relevant
> specifications and (well-known) implementations before we conclude that we
> have to devise our own behavior.
>
> Sure ... but we can only decide to do things that the implementation
> can support, and running code that might fail after we've committed
> locally isn't one of them.

Yes, I understand that Postgres may not be able to conform to specifications or well-known implementations in all aspects. I'm just suggesting to take the stance "We carefully considered established industry specifications that we can base on, did our best to design the desirable behavior learned from them, but couldn't implement a few parts", rather than "We did what we like and can do."

> I think your comparison here is quite unfair. We work hard to add
> overhead in hot paths where it might cost, but the FDW case involves a
> network round-trip anyway, so the cost of an if-statement would surely
> be insignificant. I feel like you want to assume without any evidence
> that a local resolver can never be quick enough, even thought the cost
> of IPC between local processes shouldn't be that high compared to a
> network round trip. But you also want to suppose that we can run code
> that might fail late in the commit process even though there is lots
> of evidence that this will cause problems, starting with the code
> comments that clearly say so.

There may be better examples. What I wanted to say is just that I believe it's not PG developers' standard to allow serial prepare and commit. Let's make it clear what's difficult to do the 2PC from each client session in normal operation without going through the resolver.

Regards
Takayuki Tsunakawa