Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> 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 - which
specifically talks about the issue seen on Unix as appearing with the
SO_EXCLUSIVEADDRUSE parameter, which agrees with my testresults)


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


Reply via email to