From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>,
        Pg Hackers <pgsql-hackers@postgresql.org>,
        Rushabh Lathia <rushabh.lathia@gmail.com>,
        Michael Paquier <michael.paquier@gmail.com>,
        Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Subject: Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join
 directly
In-reply-to: <5A82DCCE.3060107@lab.ntt.co.jp>
References: <5A438A45.2000909@lab.ntt.co.jp> <5A57193A.2080003@lab.ntt.co.jp>
 <CA+TgmoYef9czAA1gJeqh4v47Tv=dqOp4EfdU6bV8EYkOdCwvUw@mail.gmail.com>
 <6166.1518044513@sss.pgh.pa.us>
 <CA+TgmoaxGGZyUAWQMz7c-3V85TV5-w2wmvpOYrLnALi2d9Z-dQ@mail.gmail.com>
 <5A7BE8E6.200@lab.ntt.co.jp> <28606.1518105934@sss.pgh.pa.us>
 <CA+Tgmobf+AXEwO4r0oCkvNhkaVnxPgoJaApoX+rAi0G7-N-Dyg@mail.gmail.com>
 <5A7CFDDA.8050906@lab.ntt.co.jp> <5A7D76CF.8080601@lab.ntt.co.jp>
 <CA+TgmoaAQCn0+xh3JG2avn35Lukj2NVmhxVi7hE2CwzSUQ-5ag@mail.gmail.com>
 <20134.1518201188@sss.pgh.pa.us>
 <CA+TgmoY5KNf-Y=zOdHVfa8Lmo=OMJe=dBpP-noT_1fdVK6EYPA@mail.gmail.com>
 <18653.1518297871@sss.pgh.pa.us> <5A82DCCE.3060107@lab.ntt.co.jp>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
	message dated "Tue, 13 Feb 2018 21:40:46 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29146.1519769644.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Feb 2018 17:14:04 -0500
Message-ID: <29147.1519769644@sss.pgh.pa.us>
Precedence: bulk

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> (2018/02/11 6:24), Tom Lane wrote:
>> However, jaguarundi still shows a problem:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Djaguarundi&dt=
=3D2018-02-10%2008%3A41%3A32

> I ran the postgres_fdw regression test with no sleep two times in a =

> CLOBBER_CACHE_ALWAYS-enabled build, and then the regression test with =

> the sleep (60 seconds) two times, but I couldn't reproduce that in both =

> cases.  I suspect the changes in the order of the RETURNING output there=
 =

> was still caused by autovacuum kicking in partway through the run.  So =

> to make the regression test more stable against autovacuum, I'd propose =

> to modify the regression test to disable autovacuum for the remote table=
 =

> (ie "S 1"."T 1") (and perform VACUUM ANALYZE to that table manually =

> instead) in hopes of getting that fixed.  Attached is a patch for that. =

>   I think changes added by the previous patch wouldn't make sense =

> anymore, so I removed those changes.

Ping?  We're still seeing those failures on jaguarundi.

			regards, tom lane