Thread: 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
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/ > From each according to his ability. To each according to his ability to litigate.
Attachment
On 8/30/06, Martijn van Oosterhout <kleptog@svana.org> 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.
Are you sure psql was using TCP? If you're connecting to the localhost
Yes, I was using psql -h 10.x.x.x -p 5431 dbname username
--
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?
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.
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
> 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
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
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 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend