From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Subject: | Re: Simplify backend terminate and wait logic in postgres_fdw test |
Date: | 2021-05-04 08:22:06 |
Message-ID: | YJEELnlnNVZAIdDL@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 04, 2021 at 12:43:53PM +0530, Bharath Rupireddy wrote:
> And having a retry test case with clobber cache enabled doesn't make
> sense because all the cache entries are removed/invalidated for each
> query, but the test case covers the code on non-clobber cache
> platforms, so I would like to keep it.
Yeah, I'd rather keep this test around as it is specific to connection
caches, and it is not time-consuming on fast machines in its new shape
either. Another trick we could use here could be an aggregate
checking for the number of rows returned, say:
SELECT count(pg_terminate_backend(pid, 180000)) >= 0
FROM pg_stat_activity
WHERE application_name = 'fdw_retry_check';
But using CALL as you are suggesting is much cleaner.
(Worth noting that I am out this week for Golden Week, so if this can
wait until Monday, that would be nice. I am not willing to take my
chances with the buildfarm now :p)
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2021-05-04 08:23:21 | few ideas for pgbench |
Previous Message | Drouvot, Bertrand | 2021-05-04 08:17:49 | Re: pg_upgrade can result in early wraparound on databases with high transaction load |