|From:||Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>|
|Cc:||Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Vinayak Pokale <vinpokale(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>|
|Subject:||Re: Transactions involving multiple postgres foreign servers|
|Views:||Raw Message | Whole Thread | Download mbox|
On Thu, Jan 19, 2017 at 4:04 PM, vinayak
> On 2017/01/16 17:35, Masahiko Sawada wrote:
>> On Fri, Jan 13, 2017 at 3:48 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
>>> On Fri, Jan 13, 2017 at 3:20 PM, Ashutosh Bapat
>>> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>>>>> Long time passed since original patch proposed by Ashutosh, so I
>>>>> explain again about current design and functionality of this feature.
>>>>> If you have any question, please feel free to ask.
>>>> Thanks for the summary.
>>>> [ snip ]
>>>>> Cluster-wide atomic commit
>>>>> Since the distributed transaction commit on foreign servers are
>>>>> executed independently, the transaction that modified data on the
>>>>> multiple foreign servers is not ensured that transaction did either
>>>>> all of them commit or all of them rollback. The patch adds the
>>>>> functionality that guarantees distributed transaction did either
>>>>> commit or rollback on all foreign servers. IOW the goal of this patch
>>>>> is achieving the cluster-wide atomic commit across foreign server that
>>>>> is capable two phase commit protocol.
>>>> In , I proposed that we solve the problem of supporting PREPARED
>>>> transactions involving foreign servers and in subsequent mail Vinayak
>>>> agreed to that. But this goal has wider scope than that proposal. I am
>>>> fine widening the scope, but then it would again lead to the same
>>>> discussion we had about the big picture. May be you want to share
>>>> design (or point out the parts of this design that will help) for
>>>> solving smaller problem and tone down the patch for the same.
>>> Sorry for confuse you. I'm still focusing on solving only that
>>> problem. What I was trying to say is that I think that supporting
>>> PREPARED transaction involving foreign server is the means, not the
>>> end. So once we supports PREPARED transaction involving foreign
>>> servers we can achieve cluster-wide atomic commit in a sense.
>> Attached updated patches. I fixed some bugs and add 003 patch that
>> adds TAP test for foreign transaction.
>> 003 patch depends 000 and 001 patch.
>> Please give me feedback.
> I have tested prepared transactions with foreign servers but after preparing
> the transaction
> the following error occur infinitely.
> =#INSERT INTO ft1_lt VALUES (10);
> =#INSERT INTO ft2_lt VALUES (20);
> =#PREPARE TRANSACTION 'prep_xact_with_fdw';
> 2017-01-18 15:09:48.378 JST  ERROR: function pg_fdw_resolve() does
> not exist at character 8
> 2017-01-18 15:09:48.378 JST  HINT: No function matches the given name
> and argument types. You might need to add explicit type casts.
> 2017-01-18 15:09:48.378 JST  QUERY: SELECT pg_fdw_resolve()
> 2017-01-18 15:09:48.378 JST  LOG: worker process: foreign
> transaction resolver (dbid 13119) (PID 4312) exited with exit code 1
> If we check the status on another session then it showing the status as
> =# select * from pg_fdw_xacts;
> dbid | transaction | serverid | userid | status | identifier
> 13119 | 1688 | 16388 | 10 | prepared | px_2102366504_16388_10
> 13119 | 1688 | 16389 | 10 | prepared | px_749056984_16389_10
> (2 rows)
> I think this is a bug.
Thank you for reviewing!
I think this is a bug of pg_fdw_resolver contrib module. I had
forgotten to change the SQL executed by pg_fdw_resolver process.
Attached latest version 002 patch.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
|Next Message||Simon Riggs||2017-01-19 09:17:41||Re: Password identifiers, protocol aging and SCRAM protocol|
|Previous Message||Erik Rijkers||2017-01-19 08:39:16||Re: Logical replication existing data copy|