Re: Transactions involving multiple postgres foreign servers, take 2 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Transactions involving multiple postgres foreign servers, take 2
Date
Msg-id 52747d75-26ca-9fff-cbe3-b3d4ce0020f3@oss.nttdata.com
Whole thread Raw
In response to Re: Transactions involving multiple postgres foreign servers, take 2  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses RE: Transactions involving multiple postgres foreign servers, take 2  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
List pgsql-hackers

On 2021/10/05 10:38, Masahiko Sawada wrote:
> Hi,
> 
> On Tue, Oct 5, 2021 at 9:56 AM k.jamison@fujitsu.com
> <k.jamison@fujitsu.com> wrote:
>>
>> Hi Sawada-san,
>>
>> I noticed that this thread and its set of patches have been marked with "Returned with Feedback" by yourself.
>> I find the feature (atomic commit for foreign transactions) very useful
>> and it will pave the road for having a distributed transaction management in Postgres.
>> Although we have not arrived at consensus at which approach is best,
>> there were significant reviews and major patch changes in the past 2 years.
>> By any chance, do you have any plans to continue this from where you left off?
> 
> As I could not reply to the review comments from Fujii-san for almost
> three months, I don't have enough time to move this project forward at
> least for now. That's why I marked this patch as RWF. I’d like to
> continue working on this project in my spare time but I know this is
> not a project that can be completed by using only my spare time. If
> someone wants to work on this project, I’d appreciate it and am happy
> to help.

Probably it's time to rethink the approach. The patch introduces
foreign transaction manager into PostgreSQL core, but as far as
I review the patch, its changes look overkill and too complicated.
This seems one of reasons why we could not have yet committed
the feature even after several years.

Another concern about the approach of the patch is that it needs
to change a backend so that it additionally waits for replication
during commit phase before executing PREPARE TRANSACTION
to foreign servers. Which would decrease the performance
during commit phase furthermore.

So I wonder if it's worth revisiting the original approach, i.e.,
add the atomic commit into postgres_fdw. One disadvantage of
this is that it supports atomic commit only between foreign
PostgreSQL servers, not other various data resources like MySQL.
But I'm not sure if we really want to do atomic commit between
various FDWs. Maybe supporting only postgres_fdw is enough
for most users. Thought?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Added schema level support for publication.
Next
From: Bharath Rupireddy
Date:
Subject: Re: can we add subscription TAP test option "vcregress subscriptioncheck" for MSVC builds?