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
signature.asc
Description: PGP signature
