Re: [HACKERS] Transactions involving multiple postgres foreign servers - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] Transactions involving multiple postgres foreign servers
Date
Msg-id CAFjFpRc7ekbHCmAFZpnwixVdcD0WpVRzKkEtN18df_wkE_Jd8g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Transactions involving multiple postgres foreign servers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, May 11, 2018 at 12:27 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Feb 27, 2018 at 2:21 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> I might be missing your point. As for API breaking, this patch doesn't
>> break any existing FDWs. All new APIs I proposed are dedicated to 2PC.
>> In other words, FDWs that work today can continue working after this
>> patch gets committed, but if FDWs want to support atomic commit then
>> they should be updated to use new APIs. The reason why the calling of
>> FdwXactRegisterForeignServer is necessary is that the core code
>> controls the foreign servers that involved with the transaction but
>> the whether each foreign server uses 2PC option (two_phase_commit) is
>> known only on FDW code. We can eliminate the necessity of calling
>> FdwXactRegisterForeignServer by moving 2PC option from fdw-level to
>> server-level in order not to enforce calling the registering function
>> on FDWs. If we did that, the user can use the 2PC option as a
>> server-level option.
>
> Well, FdwXactRegisterForeignServer has a "bool two_phase_commit"
> argument.  If it only needs to be called by FDWs that support 2PC,
> then that argument is unnecessary.

An FDW may support 2PC but not a foreign server created using that
FDW. Without that argument all the foreign servers created using a
given FDW will need to support 2PC which may not be possible.

> If it needs to be called by all
> FDWs, then it breaks existing FDWs that don't call it.
>

That's true. By default FDWs, which do not want to use this facility,
can just pass false without any need for further change.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Postgres, fsync, and OSs (specifically linux)
Next
From: Thomas Munro
Date:
Subject: Re: Allowing printf("%m") only where it actually works