Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly
Date
Msg-id CAFjFpRdQVqCrYXN3F=jj_wftSp2gD-rPXKS-ogoQLAmrmKxwuQ@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Mar 5, 2018 at 8:51 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> (2018/03/03 5:01), Robert Haas wrote:
>>
>> On Fri, Mar 2, 2018 at 1:20 PM, Robert Haas<robertmhaas@gmail.com>  wrote:
>>>
>>> On Fri, Mar 2, 2018 at 5:35 AM, Etsuro Fujita
>>> <fujita.etsuro@lab.ntt.co.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


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: JIT compiling with LLVM v11
Next
From: Michael Paquier
Date:
Subject: Incorrect use of "an" and "a" in code comments and docs