From: | Chris Campbell <chris(at)bignerdranch(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Adding Rendezvous support to postmaster |
Date: | 2003-05-27 20:06:56 |
Message-ID: | C4438E7C-907E-11D7-AD3A-000393147784@bignerdranch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Tuesday, May 27, 2003, at 15:42 US/Eastern, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
>> Isn't "automatic discovery of optional features" what configure is all
>> about?
>
> Absolutely not. Configure chooses between alternative implementations
> of
> a constant feature set.
If configure can properly set HAVE_RENDEZVOUS, but the feature isn't
enabled unless a GUC variable is set (and the variable is disabled in
the default configuration), is that OK? HAVE_RENDEZVOUS just enables
the GUC variable processing, and 1 line in postmaster's main() that is
executed if the variable is set.
I think it would be really nice to enable Rendezvous service
advertisement if the system supports it (e.g., "#ifdef HAVE_RENDEZVOUS"
is the way to determine whether or not to advertise the service), but
since people don't like that, we could go back to my original proposal
was for a GUC variable that was disabled by default.
E.g., if your OS supports Rendezvous, but "rendezvous_service_name"
isn't configured in your postgresql.conf, no Rendezvous-related
anything will happen. The optional feature is discovered, but not
enabled. And there is no run-time cost associated with the feature
being compiled in but disabled.
- Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2003-05-28 02:09:24 | Re: [PATCHES] Sequence usage patch |
Previous Message | Peter Eisentraut | 2003-05-27 19:42:29 | Re: Adding Rendezvous support to postmaster |