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

Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> On Mon, Mar 5, 2018 at 8:51 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Totally outdated stats used in query planning causes the failures? ANALYZE
>> right before the plan-changing queries would fix the failures?

> 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.

The thing that I find curious, now that we've shut off autovacuum
altogether on those tables, is that we *still* aren't getting stable
results. How can that be? Yeah, if you add another query in the middle
you might find that changing later results, but for any fixed contents of
the test script, why isn't the buildfarm getting the same answers that the
patch author and committer got? I could believe different results on
32-bit and 64-bit hardware, but that does not seem to be quite the pattern
we're seeing.

> I think, it's time to split the file into at least two one
> for queries and one for DMLs.

That seems largely irrelevant right at this point. First we have to
explain the instability.

regards, tom lane