Listening on more than one port?
I need to be able to have postmaster (8.1.2) listen on more than one port,
eg, 5432 and some other port, such as 5431.
There does not appear to be a way to configure that. You can configure
multiple IP addresses, but not multiple ports.
If I set up a TCP port redirector like rinetd, to forward packets from port
5431 to port 5432 it appears to be forwarding packets to the right port with
a simple telnet session (based on errors in the log file) but psql still
says there is no postmaster listening on port 5431.
Is there a simple way to do this that I'm overlooking?
--
Mike Nolan
On Wed, Aug 30, 2006 at 02:42:58PM -0500, Michael Nolan wrote:
I need to be able to have postmaster (8.1.2) listen on more than one port,
eg, 5432 and some other port, such as 5431.
Why?
If I set up a TCP port redirector like rinetd, to forward packets from port
5431 to port 5432 it appears to be forwarding packets to the right port with
a simple telnet session (based on errors in the log file) but psql still
says there is no postmaster listening on port 5431.
Are you sure psql was using TCP? If you're connecting to the localhost
maybe it used UNIX domain sockets. It still needs a matching port
number there too...
Is there a simple way to do this that I'm overlooking?
Address translation in the firewall?
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
On 8/30/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
On Wed, Aug 30, 2006 at 02:42:58PM -0500, Michael Nolan wrote:
I need to be able to have postmaster (8.1.2) listen on more than one
port,
eg, 5432 and some other port, such as 5431.
Why?
Situation in a nutshell:
Production and test databases are on two separate systems inside the
firewall. The web server is at an ISP, outside the firewall.
The firewall sends all data coming from the ISP, port 5432 to a specific IP
address inside the firewall: port 5432, which is the production serve.
Test transactions need to go to the other server, which has to be the same
IP address (the address of the firewall), so it needs to be a different
port, but I'm not sure if the port translator in the firewall will do any
better at getting a response that than a port translator on the test server
does.
However, I also need the test database responding to requests on port 5432.
Are you sure psql was using TCP? If you're connecting to the localhost
maybe it used UNIX domain sockets. It still needs a matching port
number there too...
Yes, I was using psql -h 10.x.x.x -p 5431 dbname username
--
Mike Nolan
Show quoted text
Is there a simple way to do this that I'm overlooking?
Address translation in the firewall?
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/From each according to his ability. To each according to his ability to
litigate.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFE9fByIB7bNG8LQkwRAtVTAJ9BzO0OAI7uUByKau+JzXPON4LckACdGg7x
rZMpNhhmIVFWqiVtDVQYSaw=
=X/3S
-----END PGP SIGNATURE-----
If you need to run two separate databases on the same box, each with
its own port, then having two clusters would be one way to go. Each
cluster has its own postgresql.conf and so each cluster can be (must
be, if I'm not mistaken) configured to listen on a separate port.
On 8/30/06, Michael Nolan <htfoot@gmail.com> wrote:
Situation in a nutshell:
Production and test databases are on two separate systems inside the
firewall. The web server is at an ISP, outside the firewall.The firewall sends all data coming from the ISP, port 5432 to a specific IP
address inside the firewall: port 5432, which is the production serve.Test transactions need to go to the other server, which has to be the same
IP address (the address of the firewall), so it needs to be a different
port, but I'm not sure if the port translator in the firewall will do any
better at getting a response that than a port translator on the test server
does.However, I also need the test database responding to requests on port 5432.
Your firewall can probably redirect firewallhost:5431 to
insidehost:5432. If not, you could use something like simpleproxy on
insidehost to do what you want.
<http://sourceforge.net/projects/simpleproxy/>
-K
"Michael Nolan" <htfoot@gmail.com> writes:
Situation in a nutshell:
Production and test databases are on two separate systems inside the
firewall. The web server is at an ISP, outside the firewall.
The firewall sends all data coming from the ISP, port 5432 to a specific IP
address inside the firewall: port 5432, which is the production serve.
Test transactions need to go to the other server, which has to be the same
IP address (the address of the firewall), so it needs to be a different
port, but I'm not sure if the port translator in the firewall will do any
better at getting a response that than a port translator on the test server
does.
What I'd do is configure the firewall to forward connections to 5432 to
the production machine (port 5432) and forward connections to 5431 to
5432 on the devel server. There isn't any reason to have either
postmaster listening on multiple port numbers.
regards, tom lane
Obviously the test section has separate configurations to the live section -
simply have 2 databases defined in the same server 'ourlivedatabase' and
'ourtestdatabase'. This still gives one small login/config setting that
changes between live and dev.
On 31/8/2006 12:20, "Kelly Burkhart" <kelly@kkcsm.net> wrote:
On 8/30/06, Michael Nolan <htfoot@gmail.com> wrote:
Situation in a nutshell:
Production and test databases are on two separate systems inside the
firewall. The web server is at an ISP, outside the firewall.The firewall sends all data coming from the ISP, port 5432 to a specific IP
address inside the firewall: port 5432, which is the production serve.Test transactions need to go to the other server, which has to be the same
IP address (the address of the firewall), so it needs to be a different
port, but I'm not sure if the port translator in the firewall will do any
better at getting a response that than a port translator on the test server
does.However, I also need the test database responding to requests on port 5432.
Your firewall can probably redirect firewallhost:5431 to
insidehost:5432. If not, you could use something like simpleproxy on
insidehost to do what you want.<http://sourceforge.net/projects/simpleproxy/>
-K
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
--
Shane Ambler
Postgres@007Marketing.com
Get Sheeky @ http://Sheeky.Biz
I prefer to have my live and test databases on separate systems, if only
because each one takes up well over 100 GB of disk space.
Our hardware firewall doesn't support port changes, but I was able to get
the rinetd port redirector working to redirect 5431 to 5432 on the test
system.. (And it works with psql now, too, I'm not sure why it didn't work
before.)
So, I've got a solution that works for me. Thanks, everyone.
That's '30' for this thread. :-)
--
Mike Nolan
Show quoted text
On 8/31/06, Shane Ambler <pgsql@007marketing.com> wrote:
Obviously the test section has separate configurations to the live section
-
simply have 2 databases defined in the same server 'ourlivedatabase' and
'ourtestdatabase'. This still gives one small login/config setting that
changes between live and dev.On 31/8/2006 12:20, "Kelly Burkhart" <kelly@kkcsm.net> wrote:
On 8/30/06, Michael Nolan <htfoot@gmail.com> wrote:
Situation in a nutshell:
Production and test databases are on two separate systems inside the
firewall. The web server is at an ISP, outside the firewall.The firewall sends all data coming from the ISP, port 5432 to a
specific IP
address inside the firewall: port 5432, which is the production serve.
Test transactions need to go to the other server, which has to be the
same
IP address (the address of the firewall), so it needs to be a different
port, but I'm not sure if the port translator in the firewall will doany
better at getting a response that than a port translator on the test
server
does.
However, I also need the test database responding to requests on port
5432.
Your firewall can probably redirect firewallhost:5431 to
insidehost:5432. If not, you could use something like simpleproxy on
insidehost to do what you want.<http://sourceforge.net/projects/simpleproxy/>
-K
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings--
Shane Ambler
Postgres@007Marketing.comGet Sheeky @ http://Sheeky.Biz
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend