Re: pg_service.conf

> On Sun, 2006-02-19 at 10:00 -0500, Mark Woodward wrote:
>> > On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
>> >> Like I said, in this thread of posts, yes there are ways of doing
>> this,
>> >> and I've been doing it for years. It is just one of the rough eges
>> that
>> >> I
>> >> think could be smoother.
>> >>
>> >> (in php)
>> >> pg_connect("dbname=geo host=dbserver");
>> >>
>> >> Could connect and query the dbserver, if the db is not on it, connect
>> to
>> >> a
>> >> database of known servers, find geo, and use that information to
>> >> connect.
>> >> It sounds like a simple thing, for sure, but to be useful, there
>> needs
>> >> to
>> >> be buy in from the group otherwise it is just some esoteric hack.
>> >
>> > It turns out what you like actually exists, lookup the "service"
>> > parameter in the connectdb string. It will read the values for the
>> > server, port, etc from a pg_service.conf file.
>> >
>> > There is an example in the tree but it looks something like the
>> following:
>> >
>> > [servicename]
>> > dbname=blah
>> > user=blah
>> > pass=blah
>> >
>> > So all you need to specify is "service=servicename" and it will grab
>> > the parameters. This allows you to change the connection without
>> > changeing the code.
>> >
>>
>> This is a great feature!!
>
> Yes, it is, but there is a distinct difference between what you asked
> for and what have been described as solutions (good though they are).

Well, true, it isn't what I want, but it makes a big step.
>
> Both services and pg_service.conf are client-side solutions. So if you
> have 20,000 clients to worry about you have some problems. What was
> proposed was a central naming service (described as a database of known
> servers) that would allow a server-side name to service mapping.

True, but the one to many cluster push solution has been dealt with so
many times that as a datacenter solution isn't too troubling.

>
> A server-side (i.e. centrally managed) name server seems like an
> improvement over the client-side solutions described, IMHO, but I'd
> leave it to others to describe how that might work. (e.g. DNS is a
> better solution than multiple distributed /etc/hosts files).

DNS isn't always a better solution than /etc/hosts, both have their pros
and cons. The /etc/hosts file is very useful for "instantaneous,"
reliable, and redundent name lookups. DNS services, espcially in a large
service environment can get bogged down. 20,000 hosts doing a lot of
lookups can require a dedicated single point of failure. OK, so you add
two DNS machines and load balance across them with a fault tollerant load
balancer, how many thousands of dollars? For how much information? A
simple "clustercpy -f targets pg_service.conf /etc" would save thousands
of dollars, increase efficiency, increase reliability, decrease electrical
costs, etc.

Don't get me wrong, DNS, as it is designed, is PERFECT for the distributed
nature of the internet, but replication of fairly static data under the
control of a central authority (the admin) is better.
>
> Best Regards, Simon Riggs
>