Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On Mon, Mar 5, 2018 at 8:51 AM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> (2018/03/03 5:01), Robert Haas wrote:
>>
>> On Fri, Mar 2, 2018 at 1:20 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>>>
>>> On Fri, Mar 2, 2018 at 5:35 AM, Etsuro Fujita
>>> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>>>
>>>> Agreed. Better safe than sorry, so I disabled autovacuum for all the
>>>> tables
>>>> created in the postgres_fdw regression test, except the ones with no
>>>> data
>>>> modification created in the sections "test handling of collations" and
>>>> "test
>>>> IMPORT FOREIGN SCHEMA". I'm attaching a patch for that.
>>>
>>>
>>> I have committed this patch. Whee!
>
>
> Thank you for taking the time on this!
>
>> And that seems to have made things worse. The failures on rhinocerous
>> look related:
>>
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=rhinoceros&br=HEAD
>
>
> Totally outdated stats used in query planning causes the failures? ANALYZE
> right before the plan-changing queries would fix the failures?
>
>> And so does this failure on chub:
>>
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chub&dt=2018-03-02%2016%3A10%3A02
>
>
> The Git log shows that this was done before the commit.

I think the testcase file for postgres_fdw has grown really large over
the time, as we have added more pushdown. Since most of the queries in
that file use the same tables created at the beginning of the file,
changes somewhere in-between (esp. DMLs) affect the following queries.
It's getting hard to add a test query in that file and expect stable
results. I think, it's time to split the file into at least two one
for queries and one for DMLs. In long term, we may have, multiple
files each handling one functionality like regress/sql/. If we do so,
it will be easier to fix such problems.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company