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

David,

Thank you for your input.

Is it correct to state that (barring the soon to be obsolete stats
collector):

- PostgreSQL only uses the configured port, who's default is 5432, via
tcp
- outgoing connections are all tcp and use random ports
- none of the other intrinsic features; replication, pg_dump,
pg_basebackup, pg_restore, etc. use any other network ports
- network ports used by extensions, even if included in the base
install, are beyond the scope of PostgreSQL documentation

Thanks again,
rik.

On Wed, Aug 10, 2022 at 8:40 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

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