Re: Simplify backend terminate and wait logic in postgres_fdw test

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

In response to

Responses

Browse pgsql-hackers by date

  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