Magnus Hagander <magnus@hagander.net> writes:
> If all we want to do is add a check that prevents two servers to start on
> the same port, we could do that trivially in a win32 specific way (since
> we'll never have unix sockets there). Just create an object in the global
> namespace named postgresql.interlock.<portnumber> or such a thing.

Does it go away automatically on postmaster crash?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> There is a related risk even on Unix machines: two postmasters can be
> started on the same port number if they have different settings of
> unix_socket_directory, and then it's indeterminate which one you will
> contact if you connect to the TCP port. I seem to recall that we
> discussed this several years ago, and didn't really find a satisfactory
> way of interlocking the TCP port per se.

I'm curious as to which Unix systems allow multiple processes to listen
on the same port at the same time.. On Linux, and I thought on most,
you get an EADDRINUSE on the listen() call (which the postmaster should
pick up on and bomb out, which it may already).

Thanks,

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGSF7HrzgMPqB3kigRAjEVAJ94qqzIcfzRLv6si7bcpN EpUFhVWQCaAi64
JRJ0H4zM2f3Y++t3cai2F54=
=H2C4
-----END PGP SIGNATURE-----

Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> There is a related risk even on Unix machines: two postmasters can be
>> started on the same port number if they have different settings of
>> unix_socket_directory, and then it's indeterminate which one you will
>> contact if you connect to the TCP port. I seem to recall that we
>> discussed this several years ago, and didn't really find a satisfactory
>> way of interlocking the TCP port per se.
>
> I'm curious as to which Unix systems allow multiple processes to listen
> on the same port at the same time.. On Linux, and I thought on most,
> you get an EADDRINUSE on the listen() call (which the postmaster should
> pick up on and bomb out, which it may already).

Linux certainly does. Windows seems to treat SO_REUSEADDR in the same
way as SO_REUSEPORT which just seems wrong.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> I wrote:
>> Uh ... so the lock-file stuff is completely broken on Windows?
>
> Not so much broken as commented out ... on looking at the code, it's
> blindingly obvious that we don't even try to create a socket lock file
> if not HAVE_UNIX_SOCKETS. Sigh.

Isn't the socket lock file only there to protect the socket?

> There is a related risk even on Unix machines: two postmasters can be
> started on the same port number if they have different settings of
> unix_socket_directory, and then it's indeterminate which one you will
> contact if you connect to the TCP port. I seem to recall that we
> discussed this several years ago, and didn't really find a satisfactory
> way of interlocking the TCP port per se.

stark@oxford:~/src/local-concurrent-psql/pgsql/src/bin/psql$ /usr/local/pgsql/bin/postgres -D /var/tmp/db2
LOG: could not bind IPv4 socket: Address already in use
HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
WARNING: could not create listen socket for "localhost"
FATAL: could not create any TCP/IP sockets

Is it possible the previous discussion related to servers with IPv6 where they
did manage to bind to one but not the other?


--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > If all we want to do is add a check that prevents two servers to start on
> > the same port, we could do that trivially in a win32 specific way (since
> > we'll never have unix sockets there). Just create an object in the global
> > namespace named postgresql.interlock.<portnumber> or such a thing.
>
> Does it go away automatically on postmaster crash?

Yes.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Magnus Hagander wrote:
> On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
>
>> Magnus Hagander <magnus@hagander.net> writes:
>>
>>> If all we want to do is add a check that prevents two servers to start on
>>> the same port, we could do that trivially in a win32 specific way (since
>>> we'll never have unix sockets there). Just create an object in the global
>>> namespace named postgresql.interlock.<portnumber> or such a thing.
>>>
>> Does it go away automatically on postmaster crash?
>>
>
> Yes.
>
>
>

Then I think it's worth adding, and I'd argue that as a low risk safety
measure we should allow it to sneak into 8.3. I'm assuming the code
involved will be quite small.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Dave Page <dpage@postgresql.org> writes:
> Stephen Frost wrote:
>> I'm curious as to which Unix systems allow multiple processes to listen
>> on the same port at the same time.. On Linux, and I thought on most,
>> you get an EADDRINUSE on the listen() call (which the postmaster should
>> pick up on and bomb out, which it may already).

> Linux certainly does.

Mmm, you're right, I misread the man page:

Setting the SO_REUSEADDR option allows the local socket address to be
reused in subsequent calls to bind(). This permits multiple
SOCK_STREAM sockets to be bound to the same local address, as long as
all existing sockets with the desired local address are in a connected
state before bind() is called for a new socket.

The bit about "connected state" is relevant here --- a listening socket
isn't connected. Time for more caffeine.

> Windows seems to treat SO_REUSEADDR in the same
> way as SO_REUSEPORT which just seems wrong.

Well, Microsoft getting standards wrong is no surprise. So what do we
want to do about it?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Tom Lane wrote:
> Setting the SO_REUSEADDR option allows the local socket address to be
> reused in subsequent calls to bind(). This permits multiple
> SOCK_STREAM sockets to be bound to the same local address, as long as
> all existing sockets with the desired local address are in a connected
> state before bind() is called for a new socket.
>
> The bit about "connected state" is relevant here --- a listening socket
> isn't connected. Time for more caffeine.
>
>

That's what I thought it meant. I am glad to see that I am not quite as
out of date as I thought I must be reading upthread :-)

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane wrote:
>> Windows seems to treat SO_REUSEADDR in the same
>> way as SO_REUSEPORT which just seems wrong.
>
> Well, Microsoft getting standards wrong is no surprise. So what do we
> want to do about it?

Microsoft did lift that code from BSD many moons ago, so it might be
worth checking if the bug actually originated there.

Assuming it didn't, then Magnus' idea sounds good to me.

Regards, Dave


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
> >
> >>Magnus Hagander <magnus@hagander.net> writes:
> >>
> >>>If all we want to do is add a check that prevents two servers to start on
> >>>the same port, we could do that trivially in a win32 specific way (since
> >>>we'll never have unix sockets there). Just create an object in the global
> >>>namespace named postgresql.interlock.<portnumber> or such a thing.
> >>>
> >>Does it go away automatically on postmaster crash?
> >
> >Yes.
>
> Then I think it's worth adding, and I'd argue that as a low risk safety
> measure we should allow it to sneak into 8.3. I'm assuming the code
> involved will be quite small.

Do you actually mean 8.2 here?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly