Re: tests against running server occasionally fail, postgres_fdw & tenk1

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Fujii Masao <fujii(at)postgresql(dot)org>
Subject: Re: tests against running server occasionally fail, postgres_fdw & tenk1
Date: 2023-02-27 19:50:27
Message-ID: 20230227195027.wjrnanesm342jcnu@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-02-27 12:42:00 -0500, Tom Lane wrote:
> I wrote:
> > Hah - I thought of a solution. We can avoid this race condition if
> > we make the remote session itself inspect pg_stat_activity and
> > return its displayed application_name. Just need a foreign table
> > that maps onto pg_stat_activity.

Sounds reasonable. I guess you could also do it with a function that is
allowed to be pushed down. But given that you already solved it this way...

I think it's worth having an example for checks like this in the postgres_fdw
tests, even if it's perhaps not worth it for the application_name GUC on its
own. We saw that the GUC test copied the debug_discard_caches use of another
test...

> I went ahead and coded it that way, and it doesn't look too awful.
> Any objections?

Looks good to me.

I think it'd be an indication of a bug around the invalidation handling if the
terminations were required. So even leaving other things aside, I prefer this
version.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melih Mutlu 2023-02-27 19:52:29 Re: Allow logical replication to copy tables in binary format
Previous Message Jeff Davis 2023-02-27 19:30:41 Re: Move defaults toward ICU in 16?