Re: Refactoring postmaster's code to cleanup after child exit

On Tue, Mar 04, 2025 at 05:58:42PM -0500, Andres Freund wrote:
> On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
>> 2. Move the pgstat_bestart() call earlier in the startup sequence, so that a
>> backend shows up in pg_stat_activity before it acquires a PGPROC entry, and
>> stays visible until after it has released its PGPROC entry. This would give
>> more visibility to backends that are starting up.
>
> We don't necessarily *have* a PGPROC entry for that backend when we run out of
> connections, no?

Exactly. If I got this thread's argument right, you cannot have a
PGPROC entry that could be plugged into pg_stat_activity that early
during the startup process when collecting the startup packet.

> For this test, could we perhaps rely on the log messages postmaster logs when
> child processes exit?
>
> 2025-03-04 17:56:12.528 EST [3509838][not initialized][:0][[unknown]] LOG: connection received: host=[local]
> 2025-03-04 17:56:12.528 EST [3509838][client backend][:0][[unknown]] FATAL: sorry, too many clients already
> 2025-03-04 17:56:12.529 EST [3509817][postmaster][:0][] DEBUG: releasing pm child slot 2
> 2025-03-04 17:56:12.529 EST [3509817][postmaster][:0][] DEBUG: client backend (PID 3509838) exited with exit code 1
>
> I.e. the test could wait for the 'client backend exited' message using
> ->wait_for_log()?

Matching expected contents in the server logs is a practice I've found
to be rather reliable, with wait_for_log(). Why not adding an
injection point with a WARNING or a LOG generated, then check the
server logs for the code path taken based on the elog() generated with
the point name?
--
Michael