Re: Adding Rendezvous support to postmaster

On Wednesday, Jun 11, 2003, at 10:43 US/Eastern, Bruce Momjian wrote:

> Bruce Momjian wrote:
>> Tom Lane wrote:
>>> Bruce Momjian  writes:
>>>> I also _didn't_ add the Rendezvous GUC variable, so we default to 
>>>> the
>>>> host name.  If there is need, we can add it later.
>>>
>>> How do you figure there is not need for it?  What about running more
>>> than one postmaster at a time?
>>
>> No one brought up that idea, and Chris agreed we could try it without
>> it.  Chris, is that an issue?  I see the port number in the Rendezvous
>> function call:

Rendezvous advertises the port number of the service, yes, but the 
service name itself (which is usually related to the host name) MUST be 
unique. So if there are two postmasters running on the same machine, 
the first one will be advertised, and when the second one tries to 
register to be advertised, it will silently fail to register. It will 
still work just fine as a postmaster process, but it won't be 
advertised.

This is identical to the situation where there are two machines on the 
same network with identical Rendezvous names -- the second one to 
attempt to register a service with that name will silently fail.

Just to reassure you: nothing will break if the second postmaster fails 
to register its service name -- it just won't be advertised. That's the 
only consequence. There are no additional runtime costs, no strange log 
messages, nothing like that.

I'd love to have that GUC variable so that the service name could be 
configured...but I think that 99% of the people that will want to use 
the Rendezvous support in PostgreSQL will only be running a single 
instance of postmaster on a machine. Like you said, if people need the 
ability to configure the service name, the GUC variable can be added 
later. The way we're doing it now, Rendezvous will be enabled and the 
postmaster will be advertised by default on systems that support it. I 
like that. :) If we add the variable, then it won't be configured and 
advertised by default (I'm assuming).

> Two more issues --- first, I changed 'pgsql' to 'postgresql' as the
> service name, to match our registered TCP service name.  Second, if we
> do add a GUC variable, it has to conditionally be included in
> postgresql.conf.sample if Rendezvous is enabled.

For the first issue, "_postgresql._tcp" sounds great. For the second 
one...is conditional inclusion in postgresql.conf.sample hard? Would it 
suffice to put a "This option can only be configured on systems with 
support for Rendezvous (ex: Darwin, Mac OS X)" comment above the 
(commented out) line that configures the variable?

Thanks!

- Chris