Horton

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

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>

View thread View on postgr.es
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>, Rushabh Lathia <rushabh.lathia@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Date: 2018-02-09T01:48:10Z
Lists: pgsql-hackers 
(2018/02/09 4:32), Robert Haas wrote:
> On Thu, Feb 8, 2018 at 11:05 AM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>> According to
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinoceros&dt=2018-02-08%2001%3A45%3A01
>>
>> there's still an intermittent issue.  I ran "make installcheck" in
>> contrib/postgres_fdw in a loop, and got a similar failure on the
>> 47th try --- my result duplicates the second plan change shown by
>> rhinoceros, but not the first one.  I speculate that the plan change
>> is a result of autovacuum kicking in partway through the run.

Will look into this.

> Hmm.  Maybe inserting an ANALYZE command in the right place would fix it?

VACUUM to the right tables in the right place might better fix it? 
Another idea would be to modify test cases added by that commit so that 
they don't modify the existing tables to not break the existing test cases?

Best regards,
Etsuro Fujita

Commits

  1. Temporarily instrument postgres_fdw test to look for statistics changes.

  2. postgres_fdw: Fourth attempt to stabilize regression tests.

  3. postgres_fdw: Third attempt to stabilize regression tests.

  4. postgres_fdw: Attmempt to stabilize regression tests.

  5. postgres_fdw: Push down UPDATE/DELETE joins to remote servers.