Re: postgresql definitive list of network resources used/needed?

On Wed, Aug 10, 2022 at 4:49 PM richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com>
wrote:

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

David J.