Re: log_hostname and pg_stat_activity

On Thu, Feb 10, 2011 at 10:22 AM, Steve Singer <ssinger_pg(at)sympatico(dot)ca> wrote:
> On 11-02-10 10:13 AM, Robert Haas wrote:
>>
>> On Tue, Feb 1, 2011 at 1:33 PM, Robert Haas<robertmhaas(at)gmail(dot)com>  wrote:
>>>
>>> On Tue, Feb 1, 2011 at 1:09 PM, Peter Eisentraut<peter_e(at)gmx(dot)net>  wrote:
>>>>
>>>> On tis, 2011-01-18 at 19:24 -0500, Steve Singer wrote:
>>>>>
>>>>> However if I connect with a line in pg_hba that matches on an IP
>>>>> network then my client_hostname is always null unless log_hostname is
>>>>> set to true.  This is consistent with the behavior you describe but I
>>>>> think the average user will find it a bit confusing.  Having a column
>>>>> that is always null unless a GUC is set is less than ideal but I
>>>>> understand why log_hostname isn't on by default.
>>>>
>>>> Well, we have all these track_* variables, which also control what
>>>> appears in the statistics views.
>>>>
>>>> After thinking about this some more, I think it might be better to be
>>>> less cute and forget about the interaction with the pg_hba.conf hostname
>>>> behavior.  That is, the host name is set if and only if log_hostname is
>>>> on.
>>>
>>> +1 for doing it that way.
>>
>> I think there are no outstanding issues with this patch of any
>> significance, so I'm marking it Ready for Committer.
>>
> Was there an uodated version of this patch I missed?
>
> The original patch needed some sort of documentation saying that having
> something showup in the new pg_stat_activity columns is controlled by
> log_hostname.
>
> Above Peter and you seem to agree that having the having the line matched in
> pg_hba being a controlling factor should be removed but I haven't seen an
> updated patch that implements that.

I was assuming those changes were sufficiently trivial that they could
be made at commit-time, especially if Peter is committing it himself.
Of course if he'd like a re-review, he can always post an updated
patch, but I just thought that was overly pedantic in this particular
case.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company