Re: Adding Rendezvous support to postmaster

Here is a patch that adds a Rendezvous GUC variable to set the
Rendezvous name. Chris, would you please test this and let me know how
it works.

I know we are past cutoff, but I want to get Rendezvous completely
functional. I didn't bother with conditionally including it in
postgresql.conf because we don't do that with other options that aren't
enabled by default, like SSL and Kerberos.

---------------------------------------------------------------------------

Chris Campbell wrote:
> On Wednesday, Jun 11, 2003, at 10:43 US/Eastern, Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> >> Tom Lane wrote:
> >>> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073