From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Simplify backend terminate and wait logic in postgres_fdw test |
Date: | 2021-04-09 01:59:44 |
Message-ID: | YG+1EI+/s6sfOQjk@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 09, 2021 at 06:53:21AM +0530, Bharath Rupireddy wrote:
> I didn't think of the warning cases, my bad. How about using SET
> client_min_messages = 'ERROR'; before we call
> pg_wait_for_backend_termination? We can only depend on the return
> value of pg_wait_for_backend_termination, when true we can exit. This
> way the buildfarm will not see warnings. Thoughts?
You could do that, but I would also bet that this is going to get
forgotten in the future if this gets extended in more SQL tests that
are output-sensitive, in or out of core. Honestly, I can get behind a
warning in pg_wait_for_backend_termination() to inform that the
process poked at is not a PostgreSQL one, because it offers new and
useful information to the user. But, and my apologies for sounding a
bit noisy, I really don't get why pg_wait_until_termination() has any
need to do that. From what I can see, it provides the following
information:
- A PID, that we already know from the caller or just from
pg_stat_activity.
- A timeout, already known as well.
- The fact that the process did not terminate, information given by
the "false" status, only used in this case.
So there is no new information here to the user, only a duplicate of
what's already known to the caller of this function. I see more
advantages in removing this WARNING rather than keeping it.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2021-04-09 02:05:53 | Re: TRUNCATE on foreign table |
Previous Message | Michael Paquier | 2021-04-09 01:52:49 | Re: Lots of incorrect comments in nodeFuncs.c |