Re: Adding Rendezvous support to postmaster

From: Chris Campbell <chris(at)bignerdranch(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: aaron(at)bignerdranch(dot)com, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Adding Rendezvous support to postmaster
Date: 2003-06-11 16:29:13
Message-ID: D68B8E99-9C29-11D7-9037-000393147784@bignerdranch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Jason Tishler 2003-06-11 17:51:08 Re: Cygwin PostgreSQL CVS Patch
Previous Message Bruce Momjian 2003-06-11 15:06:01 Re: Slightly improved SSL bits...