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