Re: Adding Rendezvous support to postmaster
От | Chris Campbell |
---|---|
Тема | Re: Adding Rendezvous support to postmaster |
Дата | |
Msg-id | D68B8E99-9C29-11D7-9037-000393147784@bignerdranch.com обсуждение исходный текст |
Ответ на | Re: Adding Rendezvous support to postmaster (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Adding Rendezvous support to postmaster
(Bruce Momjian <pgman@candle.pha.pa.us>)
|
Список | pgsql-patches |
On Wednesday, Jun 11, 2003, at 10:43 US/Eastern, Bruce Momjian wrote: > Bruce Momjian wrote: >> Tom Lane wrote: >>> Bruce Momjian <pgman@candle.pha.pa.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
В списке pgsql-patches по дате отправления:
Предыдущее
От: "Mourad EL HADJ MIMOUNE"Дата:
Сообщение: [GENERAL] use of Ececute commande with PSQL