PostgreSQL 17 Service Running but Not Listening on Network Port on Windows - Mailing list pgsql-bugs

Subject: PostgreSQL 17 Service Running but Not Listening on Network Port on Windows

Environment:

• Operating System: Windows 10/11
• PostgreSQL Version: 17 (Fresh Installation)
• Testing Tools: Windows Services (services.msc), Command Prompt (netstat), DBeaver

Problem Description: A fresh installation of PostgreSQL 17 on a Windows machine starts successfully according to the Windows Services Manager, but the process fails to open its configured network port (5432). This makes it impossible for any application to connect. The issue persists even after a complete and clean reinstallation.

Key Symptoms:

• The postgresql-x64-17 service shows a status of "Running" in services.msc.
• The postgresql.conf file is correctly configured with listen_addresses = '*' and port = 5432.
• The command netstat -aon | findstr "LISTEN" | findstr "postgres" returns no output, proving the process is not listening on any port.
• The command netstat -aon | findstr ":5432" also returns no output, proving no other application is conflicting on that port.

Troubleshooting Steps Performed:

1. Verified the PostgreSQL service is "Running" after every configuration change.
2. Verified the postgresql.conf settings (listen_addresses and port).
3. Confirmed no other application is using port 5432 via netstat.
4. Created a specific port-based inbound rule in Windows Defender Firewall to allow all TCP connections on port 5432.
5. Created a more robust program-based inbound rule in Windows Defender Firewall for the postgres.exe executable (C:\Program Files\PostgreSQL\17\bin\postgres.exe).
6. Restarted the PostgreSQL service after every configuration change.
7. Performed a full uninstall, manual folder deletion, reboot, and clean reinstallation of PostgreSQL 17. (Note: The same issue was observed when testing with PostgreSQL 16).
8. Considered and ruled out third-party antivirus as the user has none.

Conclusion: The evidence strongly suggests the issue is not with the PostgreSQL configuration but with a low-level environmental factor on this specific Windows machine (e.g., a hidden security policy, a third-party security application that is not Windows Defender, or a corrupted Windows networking stack) that is preventing the postgres.exe process from successfully binding to a TCP socket.

Given that the PostgreSQL configuration is correct and standard firewall troubleshooting has been performed, the root cause appears to be an environmental issue on my Windows machine that is blocking the postgres.exe process from binding to its network port.

My question is: What other, less common Windows-level factors could cause this specific behavior?

For example, could this be related to:

• Specific Group Policies (secpol.msc)?
• Permissions issues tied to the 'Network Service' account that PostgreSQL runs under?
• Conflicts with specific VPN software, virtualization software (like Hyper-V), or other low-level network drivers?
• A known bug with the Windows networking stack itself?

Any suggestions for deeper diagnostic steps or potential hidden conflicts on Windows would be greatly appreciated."