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

From Masahiko Sawada
Subject Re: [HACKERS] Transactions involving multiple postgres foreign servers
Date
Msg-id CAD21AoBa9GOk9sx8=+hc2UxtO5XNmuewX1YCf5LunCxnVfQCJg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Transactions involving multiple postgres foreign servers  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
On Mon, Jan 1, 2018 at 7:12 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> On Thu, Dec 28, 2017 at 11:08 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>
>>> (1)
>>> Why don't you use the existing global variable MyXactFlags instead of the new TransactionDidWrite?  Or, how about
usingXactLastRecEnd != 0 to determine the transaction did any writes?  When the transaction only modified temporary
tableson the local database and some data on one remote database, I think 2pc is unnecessary. 
>>
>> Perhaps we can use (XactLastRecEnd != 0 && markXidCommitted) to see if
>> we did any writes on local node which requires the atomic commit. Will
>> fix.
>>
>
> I haven't checked how much code it needs to track whether the local
> transaction wrote anything. But probably we can post-pone this
> optimization. If it's easy to incorporate, it's good to have in the
> first set itself.
>

Without the track of local writes, we always have to use two-phase
commit even when the transaction write data on only one foreign
server. It will be cause of unnecessary performance degradation and
cause of transaction failure on existing systems. We can set the using
two-phase commit per foreign server by ALTER SERVER but it will affect
other transactions. If we can configure it per transaction perhaps it
will be worth to postpone.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unimpressed with pg_attribute_always_inline
Next
From: Peter Eisentraut
Date:
Subject: Re: Unimpressed with pg_attribute_always_inline