Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> + sprintf(mutexName,"postgresql.interlock.%i", portNumber);
>
> That won't do; it should be legal for two postmasters to listen on
> different IP addresses using the same port number. So you need to
> include some representation of the IP address being bound to.
>
>> + if (GetLastError() == ERROR_ALREADY_EXISTS)
>> + ereport(FATAL,
>> + (errcode(ERRCODE_LOCK_FILE_EXISTS),
>> + errmsg("interlock mutex \"%s\" already exists", mutexName),
>> + errhint("Is another postgres listening on port %i", portNumber)));
>
> ereport(FATAL) is quite inappropriate here. Do the same thing that
> bind() failure would do, ie, ereport(LOG) and continue the loop.
> Also, you probably need to think about cleaning up the mutex in
> case one of the later steps of socket-acquisition fails. We should
> only be holding locks on addresses we've successfully bound.
I've done some further research on this on Win32, and I've come up with
the following:
If I set the flag SO_EXCLUSIVEADDRUSE, I get the same behavior as on
Unix: Can only create one postmaster at a time on the same addr/port,
and if I close the backend with a psql session running I can't create a
new one until there is a timeout passed.
However, if I just *skip* setting SO_REUSEADDR completely, things seem
to work the way we want it. I cannot start more than one postmaster on
the same addr/port. If I start a psql, then terminate postmaster, I can
restart a new postmaster right away.
Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32.
Anybody see a problem with this?
(A fairly good reference to read up on the options is at
http://msdn2.microsoft.com/en-us/library/ms740621.aspx - which
specifically talks about the issue seen on Unix as appearing with the
SO_EXCLUSIVEADDRUSE parameter, which agrees with my testresults)
//Magnus