Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Apr 13, 2021 at 04:39:58PM +0900, Michael Paquier wrote:
>> Looks fine to me. Let's wait a bit first to see if Fujii-san has any
>> objections to this cleanup as that's his code originally, from
>> 32a9c0bd.
> And hearing nothing, done. The tests of postgres_fdw are getting much
> faster for me now, from basically 6s to 4s (actually that's roughly
> 1.8s of gain as pg_wait_until_termination waits at least 100ms,
> twice), so that's a nice gain.
The buildfarm is showing that one of these test queries is not stable
under CLOBBER_CACHE_ALWAYS:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax&dt=2021-05-01%2007%3A44%3A47
of which the relevant part is:
diff -U3 /home/buildfarm/buildroot/HEAD/pgsql.build/contrib/postgres_fdw/expected/postgres_fdw.out
/home/buildfarm/buildroot/HEAD/pgsql.build/contrib/postgres_fdw/results/postgres_fdw.out
--- /home/buildfarm/buildroot/HEAD/pgsql.build/contrib/postgres_fdw/expected/postgres_fdw.out 2021-05-01
03:44:45.022300613-0400
+++ /home/buildfarm/buildroot/HEAD/pgsql.build/contrib/postgres_fdw/results/postgres_fdw.out 2021-05-03
09:11:24.051379288-0400
@@ -9215,8 +9215,7 @@
WHERE application_name = 'fdw_retry_check';
pg_terminate_backend
----------------------
- t
-(1 row)
+(0 rows)
-- This query should detect the broken connection when starting new remote
-- transaction, reestablish new connection, and then succeed.
I can reproduce that locally by setting
alter system set debug_invalidate_system_caches_always = 1;
and running "make installcheck" in contrib/postgres_fdw.
(It takes a good long time to run the whole test script
though, so you might want to see if running just these few
queries is enough.)
There's no evidence of distress in the postmaster log,
so I suspect this might just be a timing instability,
e.g. remote process already gone before local process
looks. If so, it's probably hopeless to make this
test stable as-is. Perhaps we should just take it out.
regards, tom lane
