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

On 05/03/2025 01:23, Michael Paquier wrote:
> 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.

That's true in general; once you start running out of connections, you
can indeed run out PGPROC slots too. In this particular case, though,
there were still PGPROC slots available, reserved for superuser
connections, so it would've helped.

We could also have more pg_stat_activity slots than PGPROC slots, or
just have a few more PGPROC slots than what is required by MaxBackends.

>> 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?

Hmm, yeah, watching for "releasing pm child slot" or an explicit
injection point would work.

--
Heikki Linnakangas
Neon (https://neon.tech)