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 | 392c5e5e-6710-79a6-8244-b72ecfd695d6@oss.nttdata.com Whole thread Raw |
| In response to | Re: Transactions involving multiple postgres foreign servers, take 2 (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
| Responses |
Re: Transactions involving multiple postgres foreign servers, take 2
|
| List | pgsql-hackers |
On 2020/07/27 15:59, Masahiko Sawada wrote:
> On Thu, 23 Jul 2020 at 22:51, Muhammad Usama <m.usama@gmail.com> wrote:
>>
>>
>>
>> On Wed, Jul 22, 2020 at 12:42 PM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote:
>>>
>>> On Sat, 18 Jul 2020 at 01:55, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2020/07/16 14:47, Masahiko Sawada wrote:
>>>>> On Tue, 14 Jul 2020 at 11:19, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2020/07/14 9:08, Masahiro Ikeda wrote:
>>>>>>>> I've attached the latest version patches. I've incorporated the review
>>>>>>>> comments I got so far and improved locking strategy.
>>>>>>>
>>>>>>> Thanks for updating the patch!
>>>>>>
>>>>>> +1
>>>>>> I'm interested in these patches and now studying them. While checking
>>>>>> the behaviors of the patched PostgreSQL, I got three comments.
>>>>>
>>>>> Thank you for testing this patch!
>>>>>
>>>>>>
>>>>>> 1. We can access to the foreign table even during recovery in the HEAD.
>>>>>> But in the patched version, when I did that, I got the following error.
>>>>>> Is this intentional?
>>>>>>
>>>>>> ERROR: cannot assign TransactionIds during recovery
>>>>>
>>>>> No, it should be fixed. I'm going to fix this by not collecting
>>>>> participants for atomic commit during recovery.
>>>>
>>>> Thanks for trying to fix the issues!
>>>>
>>>> I'd like to report one more issue. When I started new transaction
>>>> in the local server, executed INSERT in the remote server via
>>>> postgres_fdw and then quit psql, I got the following assertion failure.
>>>>
>>>> TRAP: FailedAssertion("fdwxact", File: "fdwxact.c", Line: 1570)
>>>> 0 postgres 0x000000010d52f3c0 ExceptionalCondition + 160
>>>> 1 postgres 0x000000010cefbc49 ForgetAllFdwXactParticipants + 313
>>>> 2 postgres 0x000000010cefff14 AtProcExit_FdwXact + 20
>>>> 3 postgres 0x000000010d313fe3 shmem_exit + 179
>>>> 4 postgres 0x000000010d313e7a proc_exit_prepare + 122
>>>> 5 postgres 0x000000010d313da3 proc_exit + 19
>>>> 6 postgres 0x000000010d35112f PostgresMain + 3711
>>>> 7 postgres 0x000000010d27bb3a BackendRun + 570
>>>> 8 postgres 0x000000010d27af6b BackendStartup + 475
>>>> 9 postgres 0x000000010d279ed1 ServerLoop + 593
>>>> 10 postgres 0x000000010d277940 PostmasterMain + 6016
>>>> 11 postgres 0x000000010d1597b9 main + 761
>>>> 12 libdyld.dylib 0x00007fff7161e3d5 start + 1
>>>> 13 ??? 0x0000000000000003 0x0 + 3
>>>>
>>>
>>> Thank you for reporting the issue!
>>>
>>> I've attached the latest version patch that incorporated all comments
>>> I got so far. I've removed the patch adding the 'prefer' mode of
>>> foreign_twophase_commit to keep the patch set simple.
>>
>>
>> I have started to review the patchset. Just a quick comment.
>>
>> Patch v24-0002-Support-atomic-commit-among-multiple-foreign-ser.patch
>> contains changes (adding fdwxact includes) for
>> src/backend/executor/nodeForeignscan.c, src/backend/executor/nodeModifyTable.c
>> and src/backend/executor/execPartition.c files that doesn't seem to be
>> required with the latest version.
>
> Thanks for your comment.
>
> Right. I've removed these changes on the local branch.
The latest patches failed to be applied to the master branch. Could you rebase the patches?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
pgsql-hackers by date: