Re: 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

Chris Campbell <chris(at)bignerdranch(dot)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(at)bignerdranch(dot)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(at)bignerdranch(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)gmx(dot)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(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

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(at)gmx(dot)net

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

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(at)gmx(dot)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(at)gmx(dot)net

At 2:30 AM -0400 5/26/03, Tom Lane wrote:
>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

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(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

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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
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

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(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

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?

regards, tom lane

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:

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(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

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:
>
> 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(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

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

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