Re: RHEL repo package crc mismatches
Hello Evan, we have exactly the same problem and don't feel comfortable with it at the moment either. We even synchronise several versions and this problem occurs with all of them. Can anyone confirm that the packages have not been changed inadvertently but only the metadata is wrong? Here are the changes with us. For the pgdg11 RHEL 7 repository: [MIRROR] ogr_fdw_11-1.1.0-1.rhel7.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: c61d0bb8cdc2c386b57d8968b509f9fe7bf7693b3f86af730128797d087c0caa(sha256) Expected: a963ae2eb874da055db63953cf0eb0d62e24d16abd6e8d4dab615ba4fadaefd8(sha256) [MIRROR] ogr_fdw_11-llvmjit-1.1.0-1.rhel7.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 1be687c8721e7683f7efbfe51b9bd9532f7c7326d344e83e8928667cbc524cd3(sha256) Expected: 52aa7c905fd802bfea5cf7e89b80b7523b2a16309575cdbe9d68df4179ec1f6b(sha256) [MIRROR] pg_auto_failover_11-1.6.3-1.rhel7.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: abd1ede633fe8dc7721e1e09783e300c8d5a5e9b226257c67969e2bfbf7ce4f9(sha256) Expected: 0b29fc748639210c76af4b1870772780ba13a04698886e78514e7fb1baac9781(sha256) For the pgdg13 RHEL 7 repository: [MIRROR] ogr_fdw_13-1.1.0-1.rhel7.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: d2ea23dc8b866c09eb620187e40147daae1a60f2a31370a88fd119b08a5f8816(sha256) Expected: a39bc56ebc34de96321af69f99862819fe36516775cb155f599c839c098a0030(sha256) [MIRROR] ogr_fdw_13-llvmjit-1.1.0-1.rhel7.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: f2d981ba5ae5e54ac420f881c27eaba3af6b506638feed9f686273272083b479(sha256) Expected: 5e6baa1e8169da8251f4a3c47c8db0ab4344977c0ed4a8f1042d353a50e4e304(sha256) [MIRROR] pg_auto_failover_13-1.6.3-1.rhel7.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 01ce463c8487d52986e347025266167135f0a866c37590c784e7e3e5d8e43817(sha256) Expected: e35c32a27f5c97596d74fca03e416cb743bf188fdc0dfaf736cc68a20801a5c9(sha256) For the pgdg14 RHEL 7 repository: [MIRROR] pg_auto_failover_14-1.6.3-1.rhel7.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 7b72deadb029a8752717c832cde2e23d87e341037765086d88ac6d96816ebe89(sha256) Expected: 55de94cebb1967c4f1edb1a0be14246173c05168261a76d141e819f607e83ee3(sha256) Thank you for checking. Greetings Michael 3. Mai 2023 09:00, "Evan Rempel" schrieb: > At our site we use reposync to copy the postgresql repositories to a local > repository. > > When doing this on April 28 (and since) I exprience the following package > checksum matching errors. > > For the pgdg13 RHEL 8 repository > > [MIRROR] pg_auto_failover_13-1.6.3-1.rhel8.x86_64.rpm: Downloading > successful, but checksum doesn't > match. Calculated: > 5196edcfe1d6af6c0e90ad9a25667613bdfa0731a84fa9a1dbaa7080b4a3caac(sha256) > Expected: > 8d4527c96e9c8a3ff86d75aa85c166899ee895e9522c6720223f0f93b658f8d6(sha256) > > [MIRROR] e-maj_13-4.0.1-1.rhel8.x86_64.rpm: Downloading successful, but > checksum doesn't match. > Calculated: > f7576cb1cd22303cb3dbb2a86911ad3f9e57afa8472a31f1a6a1f176f708fa1d(sha256) > Expected: > 8c56cacb99771c4f06be2551988e553a70ea5e5459202e12e0e92fdeb7371621(sha256) > > For the pgdg12 RHEL 8 repository > > [MIRROR] pg_auto_failover_12-llvmjit-1.6.3-1.rhel8.x86_64.rpm: Downloading > successful, but checksum > doesn't match. Calculated: > 9bfdaccc3a151fd847bbb5e622a9384648cf963faacd90dc9b31cd433e23a3c0(sha256) > Expected: > aa5e3dc99cabfe22839ed0b9501a0099af139bf8551344a3b198ac048218ceee(sha256) > > I think it is just metadata information, but it sounds scary. > > Can anyone comment? > > -- > Evan
Re: RHEL repo package crc mismatches
Hello Bruce, Thanks for the update. Let's see what will come out. Greetings Michael 3. Mai 2023 18:57, "Bruce Momjian" schrieb: > The packagers are researching this problem now. > > --- > > On Wed, May 3, 2023 at 07:33:02AM +, Brainmue wrote: > >> Hello Evan, >> >> we have exactly the same problem and don't feel comfortable with it at the >> moment either. >> We even synchronise several versions and this problem occurs with all of >> them. >> Can anyone confirm that the packages have not been changed inadvertently but >> only the metadata is >> wrong? >> Here are the changes with us. >> >> For the pgdg11 RHEL 7 repository: >> >> [MIRROR] ogr_fdw_11-1.1.0-1.rhel7.x86_64.rpm: Downloading successful, but >> checksum doesn't match. >> Calculated: >> c61d0bb8cdc2c386b57d8968b509f9fe7bf7693b3f86af730128797d087c0caa(sha256) >> Expected: >> a963ae2eb874da055db63953cf0eb0d62e24d16abd6e8d4dab615ba4fadaefd8(sha256) >> [MIRROR] ogr_fdw_11-llvmjit-1.1.0-1.rhel7.x86_64.rpm: Downloading >> successful, but checksum doesn't >> match. Calculated: >> 1be687c8721e7683f7efbfe51b9bd9532f7c7326d344e83e8928667cbc524cd3(sha256) >> Expected: >> 52aa7c905fd802bfea5cf7e89b80b7523b2a16309575cdbe9d68df4179ec1f6b(sha256) >> [MIRROR] pg_auto_failover_11-1.6.3-1.rhel7.x86_64.rpm: Downloading >> successful, but checksum doesn't >> match. Calculated: >> abd1ede633fe8dc7721e1e09783e300c8d5a5e9b226257c67969e2bfbf7ce4f9(sha256) >> Expected: >> 0b29fc748639210c76af4b1870772780ba13a04698886e78514e7fb1baac9781(sha256) >> >> For the pgdg13 RHEL 7 repository: >> >> [MIRROR] ogr_fdw_13-1.1.0-1.rhel7.x86_64.rpm: Downloading successful, but >> checksum doesn't match. >> Calculated: >> d2ea23dc8b866c09eb620187e40147daae1a60f2a31370a88fd119b08a5f8816(sha256) >> Expected: >> a39bc56ebc34de96321af69f99862819fe36516775cb155f599c839c098a0030(sha256) >> [MIRROR] ogr_fdw_13-llvmjit-1.1.0-1.rhel7.x86_64.rpm: Downloading >> successful, but checksum doesn't >> match. Calculated: >> f2d981ba5ae5e54ac420f881c27eaba3af6b506638feed9f686273272083b479(sha256) >> Expected: >> 5e6baa1e8169da8251f4a3c47c8db0ab4344977c0ed4a8f1042d353a50e4e304(sha256) >> [MIRROR] pg_auto_failover_13-1.6.3-1.rhel7.x86_64.rpm: Downloading >> successful, but checksum doesn't >> match. Calculated: >> 01ce463c8487d52986e347025266167135f0a866c37590c784e7e3e5d8e43817(sha256) >> Expected: >> e35c32a27f5c97596d74fca03e416cb743bf188fdc0dfaf736cc68a20801a5c9(sha256) >> >> For the pgdg14 RHEL 7 repository: >> >> [MIRROR] pg_auto_failover_14-1.6.3-1.rhel7.x86_64.rpm: Downloading >> successful, but checksum doesn't >> match. Calculated: >> 7b72deadb029a8752717c832cde2e23d87e341037765086d88ac6d96816ebe89(sha256) >> Expected: >> 55de94cebb1967c4f1edb1a0be14246173c05168261a76d141e819f607e83ee3(sha256) >> >> Thank you for checking. >> >> Greetings >> Michael >> >> 3. Mai 2023 09:00, "Evan Rempel" schrieb: >> >> At our site we use reposync to copy the postgresql repositories to a local >> repository. >> >> When doing this on April 28 (and since) I exprience the following package >> checksum matching errors. >> >> For the pgdg13 RHEL 8 repository >> >> [MIRROR] pg_auto_failover_13-1.6.3-1.rhel8.x86_64.rpm: Downloading >> successful, but checksum doesn't >> match. Calculated: >> 5196edcfe1d6af6c0e90ad9a25667613bdfa0731a84fa9a1dbaa7080b4a3caac(sha256) >> Expected: >> 8d4527c96e9c8a3ff86d75aa85c166899ee895e9522c6720223f0f93b658f8d6(sha256) >> >> [MIRROR] e-maj_13-4.0.1-1.rhel8.x86_64.rpm: Downloading successful, but >> checksum doesn't match. >> Calculated: >> f7576cb1cd22303cb3dbb2a86911ad3f9e57afa8472a31f1a6a1f176f708fa1d(sha256) >> Expected: >> 8c56cacb99771c4f06be2551988e553a70ea5e5459202e12e0e92fdeb7371621(sha256) >> >> For the pgdg12 RHEL 8 repository >> >> [MIRROR] pg_auto_failover_12-llvmjit-1.6.3-1.rhel8.x86_64.rpm: Downloading >> successful, but checksum >> doesn't match. Calculated: >> 9bfdaccc3a151fd847bbb5e622a9384648cf963faacd90dc9b31cd433e23a3c0(sha256) >> Expected: >> aa5e3dc99cabfe22839ed0b9501a0099af139bf8551344a3b198ac048218ceee(sha256) >> >> I think it is just metadata information, but it sounds scary. >> >> Can anyone comment? >> >> -- >> Evan > > -- > Bruce Momjian https://momjian.us > EDB https://enterprisedb.com > > Embrace your flaws. They make you human, rather than perfect, > which you will never be.
Re: RHEL repo package crc mismatches
Hello Devrim, The problem is fixed in most of the repositories I synchronise, but in one I now have a new one. With the package: postgresql13-odbc-13.00.-1PGDG.rhel7.x86_64.rpm For the pgdg13 RHEL 7 repository: [MIRROR] postgresql13-odbc-13.00.-1PGDG.rhel7.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 2fa1642932c950ca5597d64a129fc78d2fb3909c898ade5f9bff4db73fb39ae5(sha256) Expected: 9ed5b91c12e072d871314bfa5e8ec991bb312f360f7d1e3af8ece78945931900(sha256) It would be great if you could correct that too. Thank you very much. Greetings Michael 4. Mai 2023 00:23, "Devrim Gündüz" schrieb: > Hi again, > > On Tue, 2023-05-02 at 12:38 -0700, Evan Rempel wrote: > >> At our site we use reposync to copy the postgresql repositories to a >> local repository. >> >> When doing this on April 28 (and since) I exprience the following >> package checksum matching errors. > > > > I can confirm that this is caused by signing unsigned packages last > week, but rsync failing to update main server(s). So this is *not* a > security issue. > > However, as a precaution, I removed problematic packages from the > repository. They were too old anyway. I did not want to push updated > checksums for the same packages. > > Please let me know if this solves your problem. > > Again, thanks for the report. > > Regards, > -- > Devrim Gündüz > Open Source Solution Architect, PostgreSQL Major Contributor > Twitter: @DevrimGunduz , @DevrimGunduzTR
Re: RHEL repo package crc mismatches
Hello Devrim, You were absolutely right. Resynchronising solved the problem. Now everything is OK again. Thanks for the quick help. Greetings Michael 4. Mai 2023 20:43, "Devrim Gündüz" schrieb: > Hi Michael, > > On Thu, 2023-05-04 at 04:46 +, Brainmue wrote: > >> The problem is fixed in most of the repositories I synchronise, but in >> one I now have a new one. With the package: postgresql13-odbc- >> 13.00.-1PGDG.rhel7.x86_64.rpm >> >> For the pgdg13 RHEL 7 repository: >> >> [MIRROR] postgresql13-odbc-13.00.-1PGDG.rhel7.x86_64.rpm: >> Downloading successful, but checksum doesn't match. Calculated: >> 2fa1642932c950ca5597d64a129fc78d2fb3909c898ade5f9bff4db73fb39ae5(sha25 >> 6) Expected: >> 9ed5b91c12e072d871314bfa5e8ec991bb312f360f7d1e3af8ece78945931900(sha25 >> 6) >> >> It would be great if you could correct that too. > > This package does not exist on main side, I believe you may need to sync > again. > > Regards, > -- > Devrim Gündüz > Open Source Solution Architect, PostgreSQL Major Contributor > Twitter: @DevrimGunduz , @DevrimGunduzTR
Question: Multiple pg clusters on one server can be reached with the standard port.
Hello all, I am currently looking for a solution similar to Oracle Listener. Current situation: I have a system with multiple PostgreSQL clusters for different databases. Each cluster is running on the same physical machine and is accessed through its own DNS alias and corresponding port. I only have one single IP address available, and there is no possibility of obtaining additional addresses. Here's an example: DNS ALIAS Host ─> pgs1.server.net:5432 ─> PG_Cluster1@192.168.0.1:5432 ─> pgs2.server.net:5433 ─> PG_Cluster2@192.168.0.1:5433 ─> pgs3.server.net:5434 ─> PG_Cluster3@192.168.0.1:5434 ─> pgs4.server.net:5435 ─> PG_Cluster4@192.168.0.1:5435 ─> pgs5.server.net:5436 ─> PG_Cluster5@192.168.0.1:5436 Desired solution: I still want to use the same system with different PostgreSQL clusters for the various databases. These clusters are internally accessible through different ports. However, I would like a service on the server to receive all external requests on port 5432 and forward them to the corresponding internal cluster based on the DNS alias. It would also be desirable if this service could provide additional features like connection pooling or other functionalities. Similar to a reverse proxy. Here's an example: DNS ALIAS HOST ─> pgs1.server.net:5432 ─┐ ┌──┬──> PG_Cluster1@localhost:5433 ─> pgs2.server.net:5432 ─┤ │ ├──> PG_Cluster2@localhost:5434 ─> pgs3.server.net:5432 ─┼─>─┤ 192.168.0.1:5432 ├──> PG_Cluster3@localhost:5435 ─> pgs4.server.net:5432 ─┤ │ ├──> PG_Cluster4@localhost:5436 ─> pgs5.server.net:5432 ─┘ └──┴──> PG_Cluster5@localhost:5437 Is there a solution for this, and what are the advantages or limitations that arise from it? Thank you in advance for your suggestions and help. Regards, Michael
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 12:04, "Thomas Markus" schrieb: > Hi > > Am 16.06.23 um 11:40 schrieb Brainmue: > >> Hello all, >> >> I am currently looking for a solution similar to Oracle Listener. >> >> Current situation: >> I have a system with multiple PostgreSQL clusters for different databases. >> Each cluster is running on the same physical machine and is accessed through >> its own DNS alias and >> corresponding port. >> I only have one single IP address available, and there is no possibility of >> obtaining additional >> addresses. >> >> Here's an example: >> >> DNS ALIAS Host >> ─> pgs1.server.net:5432 ─> PG_Cluster1@192.168.0.1:5432 >> ─> pgs2.server.net:5433 ─> PG_Cluster2@192.168.0.1:5433 >> ─> pgs3.server.net:5434 ─> PG_Cluster3@192.168.0.1:5434 >> ─> pgs4.server.net:5435 ─> PG_Cluster4@192.168.0.1:5435 >> ─> pgs5.server.net:5436 ─> PG_Cluster5@192.168.0.1:5436 >> >> Desired solution: >> I still want to use the same system with different PostgreSQL clusters for >> the various databases. >> These clusters are internally accessible through different ports. >> However, I would like a service on the server to receive all external >> requests on port 5432 and >> forward them to the corresponding internal cluster based on the DNS alias. >> It would also be desirable if this service could provide additional features >> like connection >> pooling or other functionalities. >> Similar to a reverse proxy. >> >> Here's an example: >> >> DNS ALIAS HOST >> ─> pgs1.server.net:5432 ─┐ ┌──┬──> PG_Cluster1@localhost:5433 >> ─> pgs2.server.net:5432 ─┤ │ ├──> PG_Cluster2@localhost:5434 >> ─> pgs3.server.net:5432 ─┼─>─┤ 192.168.0.1:5432 ├──> >> PG_Cluster3@localhost:5435 >> ─> pgs4.server.net:5432 ─┤ │ ├──> PG_Cluster4@localhost:5436 >> ─> pgs5.server.net:5432 ─┘ └──┴──> PG_Cluster5@localhost:5437 >> >> Is there a solution for this, and what are the advantages or limitations >> that arise from it? >> >> Thank you in advance for your suggestions and help. >> >> Regards, >> Michael > > possible solutions: > * set up a firewall rule to forward connection > * use a tcp proxy (nginx can do that) > * check pg_bouncer > > best regards > Thomas Hello Thomas, Thank you for your quick reply. With firewall you mean an additional software, right? Because with iptables or netfilter I can't forward TCP packets based on the DNS alias name. Or is that possible? I have the same problem with nginx. I just looked in the documentation again but I can't find a way to distinguish which cluster to forward to based on the DNS alias. Do you have an example for me? We have already looked at pgbouncer and it works with that but unfortunately you have to do the authentication in pgbouncer. Which we don't like so much. Regards, Michael
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 14:13, "Laurenz Albe" schrieb: > On Fri, 2023-06-16 at 09:40 +0000, Brainmue wrote: > >> I am currently looking for a solution similar to Oracle Listener. > > Can you explain why? Perhaps there exists a good solution for the > underlying problem. > > Yours, > Laurenz Albe Hello Laurenz, I can try. 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. We can manage very flexible moves without informing the application or even requiring changes from them. Of course, there would also be the solution of always assigning a certain fixed port to each application, but we have a lot of network segmentation with many firewalls in between. This would require a lot of organisational effort. That is the idea behind it. Regards, Michael
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 14:50, "Laurenz Albe" 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 > > Yours, > Laurenz Albe 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.
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 17:18, "Laurenz Albe" schrieb: > On Fri, 2023-06-16 at 14:49 +0000, Brainmue wrote: > >> 16. Juni 2023 14:50, "Laurenz Albe" schrieb: >> >> On Fri, 2023-06-16 at 12:35 +, 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
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 17:41, "Ron" schrieb: > On 6/16/23 10:18, Laurenz Albe wrote: > >> On Fri, 2023-06-16 at 14:49 +, Brainmue wrote: > > 16. Juni 2023 14:50, "Laurenz Albe" schrieb: >> On Fri, 2023-06-16 at 12:35 +, 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. > > In practice, that gets very complicated is large organizations: every time > you add another > database, you must file another request with the CISO RISK office to get yet > another non-standard > port open from dozens of machines, and the network team implement them. > > Operationally much simpler to have a listener handle that. > > -- Born in Arizona, moved to Babylonia. Hello Ron, I have to agree with you there as well. The workflow you have to go through is also often a time issue. There are many places that have to agree and then application owners still have to provide justifications. At the same time, we have to be flexible and fast and allocate the resources well at any time and provide the application with the maximum possible performance. Regards Michael
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 17:59, "Ron" schrieb: > On 6/16/23 10:54, Brainmue wrote: > >> 16. Juni 2023 17:41, "Ron" schrieb: > > On 6/16/23 10:18, Laurenz Albe wrote: >> On Fri, 2023-06-16 at 14:49 +, Brainmue wrote: > > 16. Juni 2023 14:50, "Laurenz Albe" schrieb: >> On Fri, 2023-06-16 at 12:35 +, 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. > > In practice, that gets very complicated is large organizations: every time > you add another > database, you must file another request with the CISO RISK office to get yet > another non-standard > port open from dozens of machines, and the network team implement them. > > Operationally much simpler to have a listener handle that. > > -- Born in Arizona, moved to Babylonia. >> Hello Ron, >> >> I have to agree with you there as well. The workflow you have to go through >> is also often a time >> issue. >> There are many places that have to agree and then application owners still >> have to provide >> justifications. >> At the same time, we have to be flexible and fast and allocate the resources >> well at any time and >> provide the application with the maximum possible performance. > > There's always The Cloud... spinning up a new AWS RDS Postgresql is fast and > simple. (Costly, > though.) > > -- Born in Arizona, moved to Babylonia. We know that too, but our data should/must currently remain in-house on our own hardware. That is why we need a solution at our company. Regards Michael
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 18:19, "Jeff Ross" schrieb: >> We have already looked at pgbouncer and it works with that but unfortunately >> you have to do the >> authentication in pgbouncer. Which we don't like so much. >> Regards, >> Michael > You can set up pgbouncer to authenticate in postgres: > > https://www.2ndquadrant.com/en/blog/understanding-user-management-in-pgbouncer/ > See the "auth_query, auth_user" section. > > https://www.2ndquadrant.com/en/blog/pg-phriday-securing-pgbouncer/ > > Jeff Thanks for the links. We'll take a second look then. I remember that we had problems last time, but unfortunately I can't remember which ones. Regards Michael
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 18:56, "Ron" schrieb: > On 6/16/23 11:05, Brainmue wrote: > >> 16. Juni 2023 17:59, "Ron" schrieb: > > [snip] > >> There's always The Cloud... spinning up a new AWS RDS Postgresql is fast and >> simple. (Costly, >> though.) >> >> We know that too, but our data should/must currently remain in-house on our >> own hardware. >> That is why we need a solution at our company. > > Do we work for the same company??? :D > > -- Born in Arizona, moved to Babylonia. The world is small. But are not all companies the same as of 3 employees ;-) Regards Michael
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
16. Juni 2023 21:54, "Francisco Olarte" schrieb: > Michael: > > On Fri, 16. Juni 2023 at 13:53, brainmue wrote: > >> Because with iptables or netfilter I can't forward TCP packets based on the >> DNS alias name. Or is >> that possible? > > The dns alias name does not reach the listening tcp socket, it is > mapped to the target record, then finally to the A record and this is > what is used to start the tcp connection. > >> I have the same problem with nginx. > > In nginx you cannot use the dns alias, but if you are using http the > "normal" clients send it as host when they open an url. But there is > no "host" parameter in the pg protocol. There is a dbaname, which can > be used with the adequate software, like pgbouncer, but you said you > do not like it. > > You may try to write a small program which parses the startup message > and redirects the connection based on the info there. I'm not sure why > pgbouncer has not this option, but it may be because it has a lot more > option. It does not seem to be that difficult, receive the packet, > parse it, connect to remote, send it the packet and from there on just > forward traffic blindly. Parsing startup seems quite simple, > maintaining a socket pool and forwarding is simple, you could probably > prototype that in an afternoon ( if no guru replies me "but this won't > work because ). > >> I just looked in the documentation again but I can't find a way to >> distinguish which cluster to >> forward to based on the DNS alias. > > As I asaid above, DNS alias is not avalilable to the listener. On any > protocol. Things like http work because the clients send the dns alias > on some place on the default usage, but you can write an http client > which sends Host: from the uri given but connects to a different IP > address. > > Francisco Olarte. Thank you for the detailed explanations. I could not have explained it but it also seemed strange to me that it should go that way. pgbouncer I will definitely look again carefully. Maybe I already have my solution with it. Regards Michael
Re: Question: Multiple pg clusters on one server can be reached with the standard port.
19. Juni 2023 13:17, "Dominique Devienne" schrieb: > On Mon, Jun 19, 2023 at 1:01 PM Thomas Markus wrote: > >> Am 19.06.23 um 12:33 schrieb Peter J. Holzer: >>> As Francisco already pointed out, this can't work with nginx either. >> anyway, fw or nginx cant look into tcp streams > Traefik can proxy PostgreSQL, I've read, so maybe that's something you could > try. Thanks for the tip. As I understand Traefik but he can also only the same as HAProxy. So he does not read the protocol itself and can not make the distribution. PGBouncer can actually do it and it also forwards to different backends. But we are not finished with the tests yet. But it looks already good. Regards Michael
