Re: Question: Multiple pg clusters on one server can be reached with the standard port.

Brainmue <brainmue@weiller.eu>

From: "Brainmue" <brainmue@weiller.eu>
To: "Laurenz Albe" <laurenz.albe@cybertec.at>
Cc: pgsql-general@lists.postgresql.org
Date: 2023-06-16T15:39:48Z
Lists: pgsql-general
16. Juni 2023 17:18, "Laurenz Albe" <laurenz.albe@cybertec.at> schrieb:

> On Fri, 2023-06-16 at 14:49 +0000, Brainmue wrote:
> 
>> 16. Juni 2023 14:50, "Laurenz Albe" <laurenz.albe@cybertec.at> schrieb:
>> 
>> On Fri, 2023-06-16 at 12:35 +0000, Brainmue wrote:
>> 
>>> We want to minimise dependencies between the application and the associated PostgreSQL DB.
>>> The idea is that the application gets its DB alias and this is then used as a connection string.
>>> This way we can decide in the backend on which server the PostgreSQL DB is running.
>> 
>> There is an existing solution for that: the libpq connection service file:
>> https://www.postgresql.org/docs/current/libpq-pgservice.html
>> 
>> If you want to manage the connection strings centrally, you can use LDAP lookup:
>> https://www.postgresql.org/docs/current/libpq-ldap.html
>> 
>> Thank you, I already know this solution, but the LDAP solution is out of the question for us and
>> the file again means an intervention on the client. And that's exactly what we don't want.
> 
> Okay.
> 
> Then why don't you go with your original solution, but use a unique TCP port number
> for each database? There are enough port numbers available. That way, there is no
> collision and no need for a proxy to map port numbers.
> 
> Yours,
> Laurenz Albe

Thank you for dealing with our wishes.

Because we are growing more and more and we have many databases in different networks.
Therefore, we are looking for a solution that will make the firewall problem more manageable for the future.
And currently I believe that managing one more service in automation would be the lesser of two evils for us.
But that's exactly why we're looking for a service that does that at all.

Regards
Michael