Skip site navigation (1) Skip section navigation (2)

Re: BUG #4932: Upgrade 8.2.13 -> 8.4.0 - Kerberos option missing

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Peter Much <pmc(at)citylink(dot)dinoex(dot)sub(dot)org>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4932: Upgrade 8.2.13 -> 8.4.0 - Kerberos option missing
Date: 2009-07-22 18:51:30
Message-ID: (view raw or whole thread)
Lists: pgsql-bugs
On Wed, Jul 22, 2009 at 17:29, Peter Much<pmc(at)citylink(dot)dinoex(dot)sub(dot)org> wrote:
> On Wed, Jul 22, 2009 at 11:52:32AM +0200, Magnus Hagander wrote:
> ! On Wed, Jul 22, 2009 at 11:42, Peter Much<pmc(at)citylink(dot)dinoex(dot)sub(dot)org> wrote:
> Now understanding it, I bow in respect - this is indeed a fine
> improvement!

Thanks :-)

> ! > But _there_is_no_such_thing_ as a "fully qualified hostname"!
> ! In a very large part of the cases, the fully qualified hostname will
> ! be the same as the fully qualified interface name for the only
> ! interface that's configured.
> Alright, frankly and just out of band of the topic, let me say
> one thing: I am installing systems for the big commercial vendors
> for more than a decade now, and this matter was an ongoing annoyance
> all of the time.
> While at first glance it may be considered just a matter of
> convenience, the real trouble starts as soon as one does
> high-availability solutions; these will definitely break on such
> an assumption, and we end up with patching the hostname on takeover:
> so having no functional mailer, unintellegible logfiles, not knowing
> for sure on which hardware we admins are logged in, and similar
> ugliness more.
> Here I am talking about the commercial middleware vendors, who
> are really stubborn in this matter - in the OpenSource the situation
> is already a thousand times better!

If you have any suggestions for improvements on either the
documentation on the feature itself from someone who's deploying them
"for real customers", that's always interesting.

 Magnus Hagander

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-22 20:39:41
Subject: Re: BUG #4934: regression in IN with joins in subselect
Previous:From: Benjamin ReedDate: 2009-07-22 18:47:52
Subject: BUG #4934: regression in IN with joins in subselect

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group