I currently manage a number of pg servers ranging from versions 9.x-14.x. Hopefully, I'll be standing up a bunch more (v 14.x) in the near future. If I had provided a specific postgres set up, then the listing of ports used/needed wouldn't be a comprehensive listing, just a listing for that particular setup. I have boxes using physical replication, some using logical, some both. Some have postgre_fdw, some oracle_fdw, some have various other *_fdw, some both or all of the above. Some use postGIS, some don't. Some have a dozen or more active extensions, others only have a handful.
Hence my desire for a listing of the network resources needed by postgres and any of its optional add-ons.
[...]
If not great, someone should include that in the docs. If so, why? Which protocol, which ports, which features or extensions?
You qualify as a "someone", care about the issue, and the project is open source.
It is not the place of PostgreSQL's documentation to list requirements for third-party software; they need to do that themselves. Calling them "optional add-ons" implies a level of integration that doesn't apply.
We document that the server listens on TCP, on the configured port number, which has a default value of 5432. That's it. How the client-side TCP/IP stack handles port assignment for outbound connections seems like it is out of scope; is it not our responsibility to document the nuances of TCP/IP. IIUC trying to block outbound connections at the port level doesn't make sense...either block outbound or don't. It seems possible to circumvent any such rule that may exist.
If UDP on the loopback device is in scope here there is a gap in my understanding of sane firewall configurations. I don't see much point in documenting the inner workings that are now obsolete and that should someone decide to block should produce sufficient diagnostic messages in the logs so as to be readily solvable.
