Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2018-02-08T19:32:23Z
Lists: pgsql-hackers
On Thu, Feb 8, 2018 at 11:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes: >> (2018/02/08 10:40), Robert Haas wrote: >>> Uggh, I missed the fact that they were doing that. It's probably >>> actually useful test coverage, but it's not surprising that it isn't >>> stable. > >> That was my purpose, but I agree with the instability. Thanks again, >> Robert! > > 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. Hmm. Maybe inserting an ANALYZE command in the right place would fix it? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Temporarily instrument postgres_fdw test to look for statistics changes.
- c2c537c56dc3 11.0 landed
-
postgres_fdw: Fourth attempt to stabilize regression tests.
- 1733460f0205 11.0 landed
-
postgres_fdw: Third attempt to stabilize regression tests.
- 4fa396464e5f 11.0 landed
-
postgres_fdw: Attmempt to stabilize regression tests.
- 958e20e42d6c 11.0 landed
-
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
- 1bc0100d270e 11.0 landed