Thread: Adding Rendezvous support to postmaster
The attached diffs add Rendezvous support to postmaster when it's
running on Darwin (Mac OS X).
Rendezvous allows services (such as a database server) to advertise
their availability to other hosts on their link-local network, and
client programs to browse the services on the network to see what's
available. It is Apple's implementation of ZEROCONF.
http://developer.apple.com/macosx/rendezvous/
This allows client programs running on computers that are on the same
link-local network as the postgresql server to automatically find the
server's IP address and port number. This adds great ease-of-use for
end users.
I propose adding a configuration variable to postgresql.conf called
"service_name" that allows the user to specify the name used to
advertise the database service. If this variable isn't defined in the
postgresql.conf file, then no service is advertised. If it is '', then
the computer's "Rendezvous Name" is used (this is similar to the
hostname, see the link below for more info). Otherwise, if it's a
non-empty string, that string is used as the name of the service.
http://developer.apple.com/qa/qa2001/qa1228.html
If there's already a service on the network with that name, then the
service registration silently fails and no service is registered.
Rendezvous also has the notion of a service type string. It's a bit
like a domain name: I suggest we use "_pgsql._tcp." (another example
would be "_ftp._tcp.").
There's very little code involved: just 1 function call in
PostmasterMain() after postmaster has started listening on a TCP
socket. And 1 addition to the GUC list of configuration variables.
All the code is #ifdef'ed inside HAVE_RENDEZVOUS, which is only defined
in src/include/port/darwin.h. Even once we know the OS is darwin, we
still need to check to make sure that Rendezvous is available, either
by OS version, or by checking for the existence of a needed header
file, etc.
I've included patches for CVS top-of-tree and postgresql-7.3.2.
Thanks!
- Chris
Attachment
Chris Campbell <chris@bignerdranch.com> writes:
> The attached diffs add Rendezvous support to postmaster when it's
> running on Darwin (Mac OS X).
I'd object to adding a Microsoft-specific patch of this ilk, and so
I'm having a moral problem with approving of an Apple-specific one...
can you offer us a platform-independent solution?
In any case, a patch that adds a configuration variable and provides
no corresponding documentation is flat-out incomplete.
regards, tom lane
On Thursday, Mar 27, 2003, at 02:04 US/Eastern, Tom Lane wrote: > I'd object to adding a Microsoft-specific patch of this ilk, and so > I'm having a moral problem with approving of an Apple-specific one... > can you offer us a platform-independent solution? Apple's Rendezvous implementation is open-source. Specifically, the mDNSResponder program and associated API that makes ZEROCONF do its thing. So this patch isn't platform-dependent but API-dependent, and anyone could build mDNSResponder on their system to make this API available. Detecting the presence of this API simply requires some configure script wizardry to look for the header files; however, a configure script wizard I am not (which I why I just threw the #define in darwin.h). Or maybe a configure --with-zeroconf flag? At any rate, the list now has the code, so anyone interested in doing the configure script modifications can run with it. Every Darwin developer that uses postgresql that I've bounced this off of has instantly replied, "Cool! Can I have the diffs?" so it's my impression that this is a feature that users would love. And it's built on open-source software, so perhaps that solves your moral problem? :) Maybe the main source tree isn't the right place. Is there somewhere else in the distribution for providing additional features that have to be manually built and installed by the user? Thanks! - Chris
> Chris Campbell <chris@bignerdranch.com> writes: > > The attached diffs add Rendezvous support to postmaster when it's > > running on Darwin (Mac OS X). > > I'd object to adding a Microsoft-specific patch of this ilk, and so > I'm having a moral problem with approving of an Apple-specific one... > can you offer us a platform-independent solution? I think you might be over-reacting here, Tom. It's a very small patch, is incredibly useful for OS/X people and is a nice feature to have. Once we have a Win32 port, I wouldn't be surprised if we had little bit of code for running as a Windows service, etc. Chris
On Thu, 2003-03-27 at 09:34, Chris Campbell wrote: > Detecting the presence of this API simply requires some configure > script wizardry to look for the header files; however, a configure > script wizard I am not (which I why I just threw the #define in > darwin.h). Or maybe a configure --with-zeroconf flag? I agree -- IMHO, an implementation that used 'configure' would be preferable to just assuming that (a) it's automatically available on Darwin (b) it's *only* available on Darwin. Cheers, Neil
[Catching up on email after getting back in town]
Chris Campbell <chris@bignerdranch.com> writes:
> On Thursday, Mar 27, 2003, at 02:04 US/Eastern, Tom Lane wrote:
>> I'd object to adding a Microsoft-specific patch of this ilk, and so
>> I'm having a moral problem with approving of an Apple-specific one...
>> can you offer us a platform-independent solution?
> Apple's Rendezvous implementation is open-source. Specifically, the
> mDNSResponder program and associated API that makes ZEROCONF do its
> thing. So this patch isn't platform-dependent but API-dependent, and
> anyone could build mDNSResponder on their system to make this API
> available.
Well, fair enough. I concur with the other comment that the
appropriate configure test should be added, though.
regards, tom lane
I will apply this patch soon, and add a configure test looking for:
#include <DNSServiceDiscovery/DNSServiceDiscovery.h>
You reference that in your code, so it seems a logical way to set
HAVE_RENDEZVOUS.
---------------------------------------------------------------------------
Chris Campbell wrote:
> The attached diffs add Rendezvous support to postmaster when it's
> running on Darwin (Mac OS X).
>
> Rendezvous allows services (such as a database server) to advertise
> their availability to other hosts on their link-local network, and
> client programs to browse the services on the network to see what's
> available. It is Apple's implementation of ZEROCONF.
>
> http://developer.apple.com/macosx/rendezvous/
>
> This allows client programs running on computers that are on the same
> link-local network as the postgresql server to automatically find the
> server's IP address and port number. This adds great ease-of-use for
> end users.
>
> I propose adding a configuration variable to postgresql.conf called
> "service_name" that allows the user to specify the name used to
> advertise the database service. If this variable isn't defined in the
> postgresql.conf file, then no service is advertised. If it is '', then
> the computer's "Rendezvous Name" is used (this is similar to the
> hostname, see the link below for more info). Otherwise, if it's a
> non-empty string, that string is used as the name of the service.
>
> http://developer.apple.com/qa/qa2001/qa1228.html
>
> If there's already a service on the network with that name, then the
> service registration silently fails and no service is registered.
>
> Rendezvous also has the notion of a service type string. It's a bit
> like a domain name: I suggest we use "_pgsql._tcp." (another example
> would be "_ftp._tcp.").
>
> There's very little code involved: just 1 function call in
> PostmasterMain() after postmaster has started listening on a TCP
> socket. And 1 addition to the GUC list of configuration variables.
>
> All the code is #ifdef'ed inside HAVE_RENDEZVOUS, which is only defined
> in src/include/port/darwin.h. Even once we know the OS is darwin, we
> still need to check to make sure that Rendezvous is available, either
> by OS version, or by checking for the existence of a needed header
> file, etc.
>
> I've included patches for CVS top-of-tree and postgresql-7.3.2.
>
> Thanks!
>
> - Chris
>
[ Attachment, skipping... ]
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I will apply this patch soon,
> Chris Campbell wrote:
>> This allows client programs running on computers that are on the same
>> link-local network as the postgresql server to automatically find the
>> server's IP address and port number. This adds great ease-of-use for
>> end users.
Are there any security issues that we should be worrying about here?
>> Rendezvous also has the notion of a service type string. It's a bit
>> like a domain name: I suggest we use "_pgsql._tcp." (another example
>> would be "_ftp._tcp.").
Is there some central authority that we need to register this name
with?
regards, tom lane
Bruce Momjian writes: > I will apply this patch soon, and add a configure test looking for: > > #include <DNSServiceDiscovery/DNSServiceDiscovery.h> > > You reference that in your code, so it seems a logical way to set > HAVE_RENDEZVOUS. I think there should be a configure switch to turn it on or off. Compare handling of readline. Automatic discovery of optional features is evil. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I will apply this patch soon, and add a configure test looking for: > > > > #include <DNSServiceDiscovery/DNSServiceDiscovery.h> > > > > You reference that in your code, so it seems a logical way to set > > HAVE_RENDEZVOUS. > > I think there should be a configure switch to turn it on or off. Compare > handling of readline. Automatic discovery of optional features is evil. Isn't "automatic discovery of optional features" what configure is all about? We have a readline flag only because we want to force people to know when they don't have it. I see this as similar to our move to make syslog the default in all binaries that support it. I thought we were avoiding additional configure flags. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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. -- Peter Eisentraut peter_e@gmx.net
Chris Campbell writes: > 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? That isn't the point. But we need configure to produce constant results for constant inputs, because we cannot expect users to read the configure or make output to detect whether some optional package was actually detected. Then again, there are probably some security implications to this feature, so an option to turn it off might be useful anyway. In any case, this patch still needs documentation. At least, provide an explanation of the configuration parameters you add, plus a paragraph or three of whatever this feature gives to users. -- Peter Eisentraut peter_e@gmx.net
Chris Campbell writes: > Rendezvous also has the notion of a service type string. It's a bit > like a domain name: I suggest we use "_pgsql._tcp." (another example > would be "_ftp._tcp."). Maybe it would be better to use "_postgresql._tcp" for consistency with the IANA service registration (which is "postgresql"). -- Peter Eisentraut peter_e@gmx.net
At 2:30 AM -0400 5/26/03, Tom Lane wrote: >Bruce Momjian <pgman@candle.pha.pa.us> writes: >> I will apply this patch soon, > >> Chris Campbell wrote: >>> This allows client programs running on computers that are on the same >>> link-local network as the postgresql server to automatically find the >>> server's IP address and port number. This adds great ease-of-use for >>> end users. > >Are there any security issues that we should be worrying about here? Rendezvous is only a service discovery protocol. There are no security issues beyond those inherent in making the postmaster service available at all. Think nmap, simplified. There could be security implications for clients that connect via the Rendezvous name and use no other authentication to verify that they are talking to the server they expect. These risks are similar to the risks posed by DNS spoofing for example. > >> Rendezvous also has the notion of a service type string. It's a bit >>> like a domain name: I suggest we use "_pgsql._tcp." (another example >>> would be "_ftp._tcp."). > >Is there some central authority that we need to register this name >with? No, but using the IANA service registration "postgresql" would probably be the best choice. PS: It'd be nice to have a corresponding patch for psql that offered a menu of available postmasters. -pmb
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
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I will apply this patch soon, and add a configure test looking for: > > > > #include <DNSServiceDiscovery/DNSServiceDiscovery.h> > > > > You reference that in your code, so it seems a logical way to set > > HAVE_RENDEZVOUS. > > I think there should be a configure switch to turn it on or off. Compare > handling of readline. Automatic discovery of optional features is evil. OK, I will modify the rendezvous patch to be a configure switch, and remove the GUC variable. If people want to specify the rendezvous, we can add it later. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I have applied the attached Rendezvous patch. Per suggestion from Peter, a --with-rendezvous flag was added to configure. This is similar to the PAM flag we already have. 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. --------------------------------------------------------------------------- Chris Campbell wrote: > The attached diffs add Rendezvous support to postmaster when it's > running on Darwin (Mac OS X). > > Rendezvous allows services (such as a database server) to advertise > their availability to other hosts on their link-local network, and > client programs to browse the services on the network to see what's > available. It is Apple's implementation of ZEROCONF. > > http://developer.apple.com/macosx/rendezvous/ > > This allows client programs running on computers that are on the same > link-local network as the postgresql server to automatically find the > server's IP address and port number. This adds great ease-of-use for > end users. > > I propose adding a configuration variable to postgresql.conf called > "service_name" that allows the user to specify the name used to > advertise the database service. If this variable isn't defined in the > postgresql.conf file, then no service is advertised. If it is '', then > the computer's "Rendezvous Name" is used (this is similar to the > hostname, see the link below for more info). Otherwise, if it's a > non-empty string, that string is used as the name of the service. > > http://developer.apple.com/qa/qa2001/qa1228.html > > If there's already a service on the network with that name, then the > service registration silently fails and no service is registered. > > Rendezvous also has the notion of a service type string. It's a bit > like a domain name: I suggest we use "_pgsql._tcp." (another example > would be "_ftp._tcp."). > > There's very little code involved: just 1 function call in > PostmasterMain() after postmaster has started listening on a TCP > socket. And 1 addition to the GUC list of configuration variables. > > All the code is #ifdef'ed inside HAVE_RENDEZVOUS, which is only defined > in src/include/port/darwin.h. Even once we know the OS is darwin, we > still need to check to make sure that Rendezvous is available, either > by OS version, or by checking for the existence of a needed header > file, etc. > > I've included patches for CVS top-of-tree and postgresql-7.3.2. > > Thanks! > > - Chris > [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: configure =================================================================== RCS file: /cvsroot/pgsql-server/configure,v retrieving revision 1.266 diff -c -c -r1.266 configure *** configure 9 Jun 2003 03:41:47 -0000 1.266 --- configure 11 Jun 2003 06:31:31 -0000 *************** *** 866,871 **** --- 866,872 ---- --with-krb5[=DIR] build with Kerberos 5 support [/usr/athena] --with-krb-srvnam=NAME name of the service principal in Kerberos postgres --with-pam build with PAM support + --with-rendezvous build with Rendezvous support --with-openssl[=DIR] build with OpenSSL support [/usr/local/ssl] --without-readline do not use Readline --without-zlib do not use Zlib *************** *** 3361,3366 **** --- 3362,3407 ---- # + # Rendezvous + # + echo "$as_me:$LINENO: checking whether to build with Rendezvous support" >&5 + echo $ECHO_N "checking whether to build with Rendezvous support... $ECHO_C" >&6 + + + + # Check whether --with-rendezvous or --without-rendezvous was given. + if test "${with_rendezvous+set}" = set; then + withval="$with_rendezvous" + + case $withval in + yes) + + cat >>confdefs.h <<\_ACEOF + #define USE_RENDEZVOUS 1 + _ACEOF + + ;; + no) + : + ;; + *) + { { echo "$as_me:$LINENO: error: no argument expected for --with-rendezvous option" >&5 + echo "$as_me: error: no argument expected for --with-rendezvous option" >&2;} + { (exit 1); exit 1; }; } + ;; + esac + + else + with_rendezvous=no + + fi; + + echo "$as_me:$LINENO: result: $with_rendezvous" >&5 + echo "${ECHO_T}$with_rendezvous" >&6 + + + + # # OpenSSL # *************** *** 9040,9045 **** --- 9081,9199 ---- fi + if test "$with_rendezvous" = yes ; then + if test "${ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h+set}" = set; then + echo "$as_me:$LINENO: checking for DNSServiceDiscovery/DNSServiceDiscovery.h" >&5 + echo $ECHO_N "checking for DNSServiceDiscovery/DNSServiceDiscovery.h... $ECHO_C" >&6 + if test "${ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 + fi + echo "$as_me:$LINENO: result: $ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h" >&5 + echo "${ECHO_T}$ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h" >&6 + else + # Is the header compilable? + echo "$as_me:$LINENO: checking DNSServiceDiscovery/DNSServiceDiscovery.h usability" >&5 + echo $ECHO_N "checking DNSServiceDiscovery/DNSServiceDiscovery.h usability... $ECHO_C" >&6 + cat >conftest.$ac_ext <<_ACEOF + #line $LINENO "configure" + #include "confdefs.h" + $ac_includes_default + #include <DNSServiceDiscovery/DNSServiceDiscovery.h> + _ACEOF + rm -f conftest.$ac_objext + if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_header_compiler=yes + else + echo "$as_me: failed program was:" >&5 + cat conftest.$ac_ext >&5 + ac_header_compiler=no + fi + rm -f conftest.$ac_objext conftest.$ac_ext + echo "$as_me:$LINENO: result: $ac_header_compiler" >&5 + echo "${ECHO_T}$ac_header_compiler" >&6 + + # Is the header present? + echo "$as_me:$LINENO: checking DNSServiceDiscovery/DNSServiceDiscovery.h presence" >&5 + echo $ECHO_N "checking DNSServiceDiscovery/DNSServiceDiscovery.h presence... $ECHO_C" >&6 + cat >conftest.$ac_ext <<_ACEOF + #line $LINENO "configure" + #include "confdefs.h" + #include <DNSServiceDiscovery/DNSServiceDiscovery.h> + _ACEOF + if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5 + (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1 + ac_status=$? + egrep -v '^ *\+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } >/dev/null; then + if test -s conftest.err; then + ac_cpp_err=$ac_c_preproc_warn_flag + else + ac_cpp_err= + fi + else + ac_cpp_err=yes + fi + if test -z "$ac_cpp_err"; then + ac_header_preproc=yes + else + echo "$as_me: failed program was:" >&5 + cat conftest.$ac_ext >&5 + ac_header_preproc=no + fi + rm -f conftest.err conftest.$ac_ext + echo "$as_me:$LINENO: result: $ac_header_preproc" >&5 + echo "${ECHO_T}$ac_header_preproc" >&6 + + # So? What about this header? + case $ac_header_compiler:$ac_header_preproc in + yes:no ) + { echo "$as_me:$LINENO: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: accepted by the compiler, rejected by thepreprocessor!" >&5 + echo "$as_me: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: accepted by the compiler, rejected by the preprocessor!">&2;} + { echo "$as_me:$LINENO: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: proceeding with the preprocessor's result">&5 + echo "$as_me: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: proceeding with the preprocessor's result" >&2;};; + no:yes ) + { echo "$as_me:$LINENO: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: present but cannot be compiled" >&5 + echo "$as_me: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: present but cannot be compiled" >&2;} + { echo "$as_me:$LINENO: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: check for missing prerequisite headers?">&5 + echo "$as_me: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: check for missing prerequisite headers?" >&2;} + { echo "$as_me:$LINENO: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: proceeding with the preprocessor's result">&5 + echo "$as_me: WARNING: DNSServiceDiscovery/DNSServiceDiscovery.h: proceeding with the preprocessor's result" >&2;};; + esac + echo "$as_me:$LINENO: checking for DNSServiceDiscovery/DNSServiceDiscovery.h" >&5 + echo $ECHO_N "checking for DNSServiceDiscovery/DNSServiceDiscovery.h... $ECHO_C" >&6 + if test "${ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 + else + ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h=$ac_header_preproc + fi + echo "$as_me:$LINENO: result: $ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h" >&5 + echo "${ECHO_T}$ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h" >&6 + + fi + if test $ac_cv_header_DNSServiceDiscovery_DNSServiceDiscovery_h = yes; then + : + else + { { echo "$as_me:$LINENO: error: header file <DNSServiceDiscovery/DNSServiceDiscovery.h> is required for Rendezvous">&5 + echo "$as_me: error: header file <DNSServiceDiscovery/DNSServiceDiscovery.h> is required for Rendezvous" >&2;} + { (exit 1); exit 1; }; } + fi + + + fi + ## ## Types, structures, compiler characteristics *************** *** 17327,17332 **** --- 17481,17487 ---- s,@with_krb5@,$with_krb5,;t t s,@krb_srvtab@,$krb_srvtab,;t t s,@with_pam@,$with_pam,;t t + s,@with_rendezvous@,$with_rendezvous,;t t s,@with_openssl@,$with_openssl,;t t s,@ELF_SYS@,$ELF_SYS,;t t s,@THREAD_LIBS@,$THREAD_LIBS,;t t Index: configure.in =================================================================== RCS file: /cvsroot/pgsql-server/configure.in,v retrieving revision 1.257 diff -c -c -r1.257 configure.in *** configure.in 9 Jun 2003 03:41:46 -0000 1.257 --- configure.in 11 Jun 2003 06:31:33 -0000 *************** *** 472,477 **** --- 472,488 ---- # + # Rendezvous + # + AC_MSG_CHECKING([whether to build with Rendezvous support]) + PGAC_ARG_BOOL(with, rendezvous, no, + [ --with-rendezvous build with Rendezvous support], + [AC_DEFINE([USE_RENDEZVOUS], 1, [Define to 1 to build with Rendezvous support. (--with-rendezvous)])]) + AC_MSG_RESULT([$with_rendezvous]) + AC_SUBST(with_rendezvous) + + + # # OpenSSL # PGAC_ARG_OPTARG(with, openssl, *************** *** 757,762 **** --- 768,777 ---- AC_CHECK_HEADERS(security/pam_appl.h, [], [AC_CHECK_HEADERS(pam/pam_appl.h, [], [AC_MSG_ERROR([header file <security/pam_appl.h> or <pam/pam_appl.h> is required forPAM.])])]) + fi + + if test "$with_rendezvous" = yes ; then + AC_CHECK_HEADER(DNSServiceDiscovery/DNSServiceDiscovery.h, [], [AC_MSG_ERROR([header file <DNSServiceDiscovery/DNSServiceDiscovery.h>is required for Rendezvous])]) fi Index: doc/src/sgml/installation.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/installation.sgml,v retrieving revision 1.132 diff -c -c -r1.132 installation.sgml *** doc/src/sgml/installation.sgml 25 Mar 2003 16:15:36 -0000 1.132 --- doc/src/sgml/installation.sgml 11 Jun 2003 06:31:37 -0000 *************** *** 270,277 **** <listitem> <para> <application>Kerberos</>, <application>OpenSSL</>, or <application>PAM</>, ! if you want to support ! authentication using these services. </para> </listitem> </itemizedlist> --- 270,276 ---- <listitem> <para> <application>Kerberos</>, <application>OpenSSL</>, or <application>PAM</>, ! if you want to support authentication using these services. </para> </listitem> </itemizedlist> *************** *** 902,907 **** --- 901,915 ---- Prevents the use of the <application>Readline</> library. This disables command-line editing and history in <application>psql</application>, so it is not recommended. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-rendezvous</option></term> + <listitem> + <para> + Build with Rendezvous support. </para> </listitem> </varlistentry> Index: src/backend/postmaster/postmaster.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.331 diff -c -c -r1.331 postmaster.c *** src/backend/postmaster/postmaster.c 28 May 2003 19:36:28 -0000 1.331 --- src/backend/postmaster/postmaster.c 11 Jun 2003 06:31:47 -0000 *************** *** 85,90 **** --- 85,94 ---- #include <getopt.h> #endif + #ifdef USE_RENDEZVOUS + #include <DNSServiceDiscovery/DNSServiceDiscovery.h> + #endif + #include "catalog/pg_database.h" #include "commands/async.h" #include "lib/dllist.h" *************** *** 366,371 **** --- 370,386 ---- } + #ifdef USE_RENDEZVOUS + + /* reg_reply -- empty callback function for DNSServiceRegistrationCreate() */ + static void + reg_reply(DNSServiceRegistrationReplyErrorType errorCode, void *context) + { + + } + + #endif + int PostmasterMain(int argc, char *argv[]) { *************** *** 723,728 **** --- 738,755 ---- else elog(LOG, "IPv4 socket created"); } + #endif + #ifdef USE_RENDEZVOUS + if (service_name != NULL) + { + DNSServiceRegistrationCreate(NULL, /* default to hostname */ + "_postgresql._tcp.", + "", + htonl(PostPortNumber), + "", + (DNSServiceRegistrationReply)reg_reply, + NULL); + } #endif } Index: src/include/pg_config.h.in =================================================================== RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v retrieving revision 1.48 diff -c -c -r1.48 pg_config.h.in *** src/include/pg_config.h.in 27 May 2003 16:36:50 -0000 1.48 --- src/include/pg_config.h.in 11 Jun 2003 06:31:49 -0000 *************** *** 564,569 **** --- 564,572 ---- /* Define to 1 to build with PAM support. (--with-pam) */ #undef USE_PAM + /* Define to 1 to build with Rendezvous support. (--with-rendezvous) */ + #undef USE_RENDEZVOUS + /* Define to build with (Open)SSL support. (--with-openssl) */ #undef USE_SSL
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I will apply this patch soon, and add a configure test looking for: > > > > #include <DNSServiceDiscovery/DNSServiceDiscovery.h> > > > > You reference that in your code, so it seems a logical way to set > > HAVE_RENDEZVOUS. > > I think there should be a configure switch to turn it on or off. Compare > handling of readline. Automatic discovery of optional features is evil. Peter, I assume you meant to add a specific flag to _enable_ Rendezvous, which is how I handled it, rather than have it like readline where we have a flag to disable readline. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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?
regards, tom lane
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:
if (service_name != NULL)
{
DNSServiceRegistrationCreate(NULL, /* default to hostname */
"_postgresql._tcp.",
"",
htonl(PostPortNumber),
"",
(DNSServiceRegistrationReply)reg_reply,
NULL);
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
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:
>
> if (service_name != NULL)
> {
> DNSServiceRegistrationCreate(NULL, /* default to hostname */
> "_postgresql._tcp.",
> "",
> htonl(PostPortNumber),
> "",
> (DNSServiceRegistrationReply)reg_reply,
> NULL);
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.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
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
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@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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/runtime.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.193 diff -c -c -r1.193 runtime.sgml *** doc/src/sgml/runtime.sgml 14 Jul 2003 20:00:22 -0000 1.193 --- doc/src/sgml/runtime.sgml 18 Jul 2003 20:43:38 -0000 *************** *** 732,737 **** --- 732,747 ---- </listitem> </varlistentry> + <varlistentry> + <term><varname>RENDEZVOUS_NAME</varname> (<type>string</type>)</term> + <listitem> + <para> + Specifies the Rendezvous broadcast name. By default, the + local hostname is used. + </para> + </listitem> + </varlistentry> + </variablelist> </sect3> <sect3 id="runtime-config-connection-security"> Index: src/backend/postmaster/postmaster.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.333 diff -c -c -r1.333 postmaster.c *** src/backend/postmaster/postmaster.c 12 Jun 2003 07:36:51 -0000 1.333 --- src/backend/postmaster/postmaster.c 18 Jul 2003 20:43:42 -0000 *************** *** 210,215 **** --- 210,217 ---- bool Log_connections = false; bool Db_user_namespace = false; + char *rendezvous_name = NULL; + /* For FNCTL_NONBLOCK */ #if defined(WIN32) || defined(__BEOS__) long ioctlsocket_ret; *************** *** 756,772 **** "socket."); } } ! #ifdef USE_RENDEZVOUS ! if (service_name != NULL) ! { ! DNSServiceRegistrationCreate(NULL, /* default to hostname */ ! "_postgresql._tcp.", ! "", ! htonl(PostPortNumber), ! "", ! (DNSServiceRegistrationReply)reg_reply, ! NULL); ! } #endif } --- 758,775 ---- "socket."); } } ! #ifdef USE_RENDEZVOUS ! if (service_name != NULL) ! { ! DNSServiceRegistrationCreate((rendezvous_name && strlen(rendezvous_name) > 0)) ? ! rendezvous_name : NULL, /* default to hostname */ ! "_postgresql._tcp.", ! "", ! htonl(PostPortNumber), ! "", ! (DNSServiceRegistrationReply)reg_reply, ! NULL); ! } #endif } Index: src/backend/utils/misc/guc.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v retrieving revision 1.137 diff -c -c -r1.137 guc.c *** src/backend/utils/misc/guc.c 15 Jul 2003 19:19:56 -0000 1.137 --- src/backend/utils/misc/guc.c 18 Jul 2003 20:43:47 -0000 *************** *** 1299,1304 **** --- 1299,1313 ---- PG_KRB_SRVTAB, NULL, NULL }, + { + {"rendezvous_name", PGC_POSTMASTER, CONN_AUTH_SETTINGS, + gettext_noop("The Rendezvous broadcast service name"), + NULL + }, + &rendezvous_name, + NULL /* defaults to local hostname */, NULL, NULL + }, + /* See main.c about why defaults for LC_foo are not all alike */ { Index: src/backend/utils/misc/postgresql.conf.sample =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v retrieving revision 1.85 diff -c -c -r1.85 postgresql.conf.sample *** src/backend/utils/misc/postgresql.conf.sample 18 Jul 2003 19:16:03 -0000 1.85 --- src/backend/utils/misc/postgresql.conf.sample 18 Jul 2003 20:43:47 -0000 *************** *** 38,43 **** --- 38,44 ---- #unix_socket_group = '' #unix_socket_permissions = 0777 # octal #virtual_host = '' + #rendezvous_name = '' # defaults to local hostname # - Security & Authentication - Index: src/include/tcop/tcopprot.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/tcop/tcopprot.h,v retrieving revision 1.57 diff -c -c -r1.57 tcopprot.h *** src/include/tcop/tcopprot.h 5 May 2003 00:44:56 -0000 1.57 --- src/include/tcop/tcopprot.h 18 Jul 2003 20:43:48 -0000 *************** *** 32,37 **** --- 32,38 ---- extern bool log_hostname; extern bool LogSourcePort; extern DLLIMPORT const char *debug_query_string; + extern char *rendezvous_name; #ifndef BOOTSTRAP_INCLUDE
OK, new patch attached, with the adjustment you suggested. We do
probably have a few days to resolve this, but if we run out of time, I
will drop it like a hot potato and keep it for 7.5. :-)
---------------------------------------------------------------------------
Chris Campbell wrote:
> On Monday, Jul 21, 2003, at 21:17 US/Eastern, Bruce Momjian wrote:
>
> > Again, why does the current code pass NULL as the first param --- that
> > was from your orignal patch.
>
> The original patch passed the service_name variable (which you've now
> renamed rendezvous_name) as the first parameter. I'm not sure how that
> NULL got there. You're correct: the first parameter is the string to
> use as the service name. To use the default (the Computer Name), ""
> should be passed (the empty string). Which, if rendezvous_name defaults
> to "", means that rendezvous_name should be passed in all cases.
>
> > I figure because we have a Rendezvous config param, then they want it
> > on
> > by default.
>
> I agree with that thinking. In my original patch, I required that a
> "service_name =" directive be in the config file to turn on Rendezvous
> service advertisement, and that "service_name = """ be in there to use
> the default service name (the Computer Name), but I like this way
> better: always advertise a service (if HAVE_RENDEZVOUS is defined) and
> use the default service name ("") unless a service name is configured
> with rendezvous_name = in the config file.
>
> I like it. I'll check out your pointers on getting initdb to work in OS
> X, make sure I've got a good looking patch, then mail you a patch to
> HEAD. Probably tomorrow? That work?
>
> Thanks!
>
> - Chris
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.193
diff -c -c -r1.193 runtime.sgml
*** doc/src/sgml/runtime.sgml 14 Jul 2003 20:00:22 -0000 1.193
--- doc/src/sgml/runtime.sgml 22 Jul 2003 03:41:50 -0000
***************
*** 732,737 ****
--- 732,747 ----
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>RENDEZVOUS_NAME</varname> (<type>string</type>)</term>
+ <listitem>
+ <para>
+ Specifies the Rendezvous broadcast name. By default, the
+ computer name is used, specified as ''.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</sect3>
<sect3 id="runtime-config-connection-security">
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.333
diff -c -c -r1.333 postmaster.c
*** src/backend/postmaster/postmaster.c 12 Jun 2003 07:36:51 -0000 1.333
--- src/backend/postmaster/postmaster.c 22 Jul 2003 03:41:54 -0000
***************
*** 210,215 ****
--- 210,217 ----
bool Log_connections = false;
bool Db_user_namespace = false;
+ char *rendezvous_name;
+
/* For FNCTL_NONBLOCK */
#if defined(WIN32) || defined(__BEOS__)
long ioctlsocket_ret;
***************
*** 756,772 ****
"socket.");
}
}
! #ifdef USE_RENDEZVOUS
! if (service_name != NULL)
! {
! DNSServiceRegistrationCreate(NULL, /* default to hostname */
! "_postgresql._tcp.",
! "",
! htonl(PostPortNumber),
! "",
! (DNSServiceRegistrationReply)reg_reply,
! NULL);
! }
#endif
}
--- 758,774 ----
"socket.");
}
}
! #ifdef USE_RENDEZVOUS
! if (service_name != NULL)
! {
! DNSServiceRegistrationCreate(rendezvous_name,
! "_postgresql._tcp.",
! "",
! htonl(PostPortNumber),
! "",
! (DNSServiceRegistrationReply)reg_reply,
! NULL);
! }
#endif
}
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.137
diff -c -c -r1.137 guc.c
*** src/backend/utils/misc/guc.c 15 Jul 2003 19:19:56 -0000 1.137
--- src/backend/utils/misc/guc.c 22 Jul 2003 03:41:59 -0000
***************
*** 1299,1304 ****
--- 1299,1313 ----
PG_KRB_SRVTAB, NULL, NULL
},
+ {
+ {"rendezvous_name", PGC_POSTMASTER, CONN_AUTH_SETTINGS,
+ gettext_noop("The Rendezvous broadcast service name"),
+ NULL
+ },
+ &rendezvous_name,
+ "", NULL, NULL
+ },
+
/* See main.c about why defaults for LC_foo are not all alike */
{
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.85
diff -c -c -r1.85 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample 18 Jul 2003 19:16:03 -0000 1.85
--- src/backend/utils/misc/postgresql.conf.sample 22 Jul 2003 03:41:59 -0000
***************
*** 38,43 ****
--- 38,44 ----
#unix_socket_group = ''
#unix_socket_permissions = 0777 # octal
#virtual_host = ''
+ #rendezvous_name = '' # defaults to the computer name
# - Security & Authentication -
Index: src/include/tcop/tcopprot.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/tcop/tcopprot.h,v
retrieving revision 1.57
diff -c -c -r1.57 tcopprot.h
*** src/include/tcop/tcopprot.h 5 May 2003 00:44:56 -0000 1.57
--- src/include/tcop/tcopprot.h 22 Jul 2003 03:42:00 -0000
***************
*** 32,37 ****
--- 32,38 ----
extern bool log_hostname;
extern bool LogSourcePort;
extern DLLIMPORT const char *debug_query_string;
+ extern char *rendezvous_name;
#ifndef BOOTSTRAP_INCLUDE
Got it. Thanks for the testing. Patch attached and applied.
---------------------------------------------------------------------------
Chris Campbell wrote:
> OK, compiled and tested. Looks good. One modification to your patch:
> there's a line that says "if (service_name != NULL)" -- that should be
> "if (rendezvous_name != NULL)" since that variable's been renamed.
> Change that, and I'm happy.
>
> Thanks!
>
> - Chris
>
> On Monday, Jul 21, 2003, at 23:50 US/Eastern, Bruce Momjian wrote:
>
> > OK, new patch attached, with the adjustment you suggested. We do
> > probably have a few days to resolve this, but if we run out of time, I
> > will drop it like a hot potato and keep it for 7.5. :-)
> >
> > -----------------------------------------------------------------------
> > ----
> >
> > Chris Campbell wrote:
> >> On Monday, Jul 21, 2003, at 21:17 US/Eastern, Bruce Momjian wrote:
> >>
> >>> Again, why does the current code pass NULL as the first param ---
> >>> that
> >>> was from your orignal patch.
> >>
> >> The original patch passed the service_name variable (which you've now
> >> renamed rendezvous_name) as the first parameter. I'm not sure how that
> >> NULL got there. You're correct: the first parameter is the string to
> >> use as the service name. To use the default (the Computer Name), ""
> >> should be passed (the empty string). Which, if rendezvous_name
> >> defaults
> >> to "", means that rendezvous_name should be passed in all cases.
> >>
> >>> I figure because we have a Rendezvous config param, then they want it
> >>> on
> >>> by default.
> >>
> >> I agree with that thinking. In my original patch, I required that a
> >> "service_name =" directive be in the config file to turn on Rendezvous
> >> service advertisement, and that "service_name = """ be in there to use
> >> the default service name (the Computer Name), but I like this way
> >> better: always advertise a service (if HAVE_RENDEZVOUS is defined) and
> >> use the default service name ("") unless a service name is configured
> >> with rendezvous_name = in the config file.
> >>
> >> I like it. I'll check out your pointers on getting initdb to work in
> >> OS
> >> X, make sure I've got a good looking patch, then mail you a patch to
> >> HEAD. Probably tomorrow? That work?
> >>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.193
diff -c -c -r1.193 runtime.sgml
*** doc/src/sgml/runtime.sgml 14 Jul 2003 20:00:22 -0000 1.193
--- doc/src/sgml/runtime.sgml 22 Jul 2003 03:41:50 -0000
***************
*** 732,737 ****
--- 732,747 ----
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>RENDEZVOUS_NAME</varname> (<type>string</type>)</term>
+ <listitem>
+ <para>
+ Specifies the Rendezvous broadcast name. By default, the
+ computer name is used, specified as ''.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</sect3>
<sect3 id="runtime-config-connection-security">
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.333
diff -c -c -r1.333 postmaster.c
*** src/backend/postmaster/postmaster.c 12 Jun 2003 07:36:51 -0000 1.333
--- src/backend/postmaster/postmaster.c 22 Jul 2003 03:41:54 -0000
***************
*** 210,215 ****
--- 210,217 ----
bool Log_connections = false;
bool Db_user_namespace = false;
+ char *rendezvous_name;
+
/* For FNCTL_NONBLOCK */
#if defined(WIN32) || defined(__BEOS__)
long ioctlsocket_ret;
***************
*** 756,772 ****
"socket.");
}
}
! #ifdef USE_RENDEZVOUS
! if (service_name != NULL)
! {
! DNSServiceRegistrationCreate(NULL, /* default to hostname */
! "_postgresql._tcp.",
! "",
! htonl(PostPortNumber),
! "",
! (DNSServiceRegistrationReply)reg_reply,
! NULL);
! }
#endif
}
--- 758,774 ----
"socket.");
}
}
! #ifdef USE_RENDEZVOUS
! if (rendezvous_name != NULL)
! {
! DNSServiceRegistrationCreate(rendezvous_name,
! "_postgresql._tcp.",
! "",
! htonl(PostPortNumber),
! "",
! (DNSServiceRegistrationReply)reg_reply,
! NULL);
! }
#endif
}
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.137
diff -c -c -r1.137 guc.c
*** src/backend/utils/misc/guc.c 15 Jul 2003 19:19:56 -0000 1.137
--- src/backend/utils/misc/guc.c 22 Jul 2003 03:41:59 -0000
***************
*** 1299,1304 ****
--- 1299,1313 ----
PG_KRB_SRVTAB, NULL, NULL
},
+ {
+ {"rendezvous_name", PGC_POSTMASTER, CONN_AUTH_SETTINGS,
+ gettext_noop("The Rendezvous broadcast service name"),
+ NULL
+ },
+ &rendezvous_name,
+ "", NULL, NULL
+ },
+
/* See main.c about why defaults for LC_foo are not all alike */
{
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.85
diff -c -c -r1.85 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample 18 Jul 2003 19:16:03 -0000 1.85
--- src/backend/utils/misc/postgresql.conf.sample 22 Jul 2003 03:41:59 -0000
***************
*** 38,43 ****
--- 38,44 ----
#unix_socket_group = ''
#unix_socket_permissions = 0777 # octal
#virtual_host = ''
+ #rendezvous_name = '' # defaults to the computer name
# - Security & Authentication -
Index: src/include/tcop/tcopprot.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/tcop/tcopprot.h,v
retrieving revision 1.57
diff -c -c -r1.57 tcopprot.h
*** src/include/tcop/tcopprot.h 5 May 2003 00:44:56 -0000 1.57
--- src/include/tcop/tcopprot.h 22 Jul 2003 03:42:00 -0000
***************
*** 32,37 ****
--- 32,38 ----
extern bool log_hostname;
extern bool LogSourcePort;
extern DLLIMPORT const char *debug_query_string;
+ extern char *rendezvous_name;
#ifndef BOOTSTRAP_INCLUDE