BUG #18955: pg_ctl output not being logged in stderr log on Windows if started with "net start"

The following bug has been logged on the website:

Bug reference: 18955
Logged by: Seva Zaslavsky
Email address: szaslavsky(at)mpcapitallp(dot)com
PostgreSQL version: 17.5
Operating system: Windows Server 2019, Windows 10
Description:

I'm working on migrating a PG cluster from PG 13.18 to 17.5 on Windows
Server 2019 I'm using the community build of PG 17.5 from EDB. I've
completed the migration using pg_upgrade.exe I've updated the default
postgresql.conf that was created by initdb with settings from my PG13.18
instance. Logging is configured exactly the same and it's running on the
same machine, same user. Issue *cannot* be reproduced if postgres is
started with "pg_ctl start"
When the PG 17.5 server is started with "net start" or in the services
administrative panel (services.msc), I don't see messages created by pg_ctl
in the stderr logs (that I see with 13.18) such as:
- database system is shut down (generated from pg_ctl stop)
- received SIGHUP, reloading configuration files (generated from pg_ctl
reload)
However I do see these messages in the logs
2025-06-06 09:59:08.718 EDT [26740] [] LOG: shutting down
2025-06-06 09:59:08.738 EDT [26740] [] LOG: checkpoint starting:
shutdown immediate
Here are my logging settings in postgresql.conf which are the same as I use
with 13.18
log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_file_mode = 0640
log_rotation_age = 1d
log_min_messages = info
log_min_duration_statement = 30000
log_checkpoints = on
log_connections = on
log_disconnections = on
log_line_prefix = '%m [%p] [%a] '
In addition to Windows Server 2019, I verified this with a fresh EDB
install on Windows 10 (after setting up stderr logging to a file). So the
way to repro is to:
1. install EDB release on windows machine
2. set up stderr logging to a file in postgresql.conf
3 start PG with "net start"
4. do a "pg_ctl reload" on command line and look for "received SIGHUP" in
log which will be missing.