Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)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
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)
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2007-06-03 21:57:07|
|Subject: Re: What is happening on buildfarm member baiji?|
|Previous:||From: Tom Lane||Date: 2007-06-03 18:53:02|
|Subject: IsTransactionState() is being used incorrectly|