Re: Transactions involving multiple postgres foreign servers, take 2

On Fri, Jul 17, 2020 at 9:56 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
wrote:

>
>
> On 2020/07/16 14:47, Masahiko Sawada wrote:
> > On Tue, 14 Jul 2020 at 11:19, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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
>

I have done a test with the latest set of patches shared by Swada and I am
not able to reproduce this issue. Started a prepared transaction on the
local server and then did a couple of inserts in a remote table using
postgres_fdw and the quit psql. I am not able to reproduce the assertion
failure.

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

--
Highgo Software (Canada/China/Pakistan)
URL : http://www.highgo.ca
ADDR: 10318 WHALLEY BLVD, Surrey, BC
EMAIL: mailto: ahsan(dot)hadi(at)highgo(dot)ca