Re: log_hostname and pg_stat_activity

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: log_hostname and pg_stat_activity
Date: 2011-01-15 16:15:45
Message-ID: 1295108145.7163.4.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On tor, 2010-12-23 at 22:21 +0100, Magnus Hagander wrote:
> On Thu, Dec 23, 2010 at 22:09, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > Somehow I fantasized that log_hostname would also turn
> > pg_stat_activity.client_addr into names instead of IP addresses. It
> > doesn't, but perhaps it should? It would be nice to be able to
> > configure an IP-address free setup. Or would it be worth having a
> > separate configuration parameter for that?
>
> It should certainly be renamed to something else if it does both, but
> I don't see the point of having two separate parameters between them.
> As long as you can use a cached version of the lookup, you're only
> paying the price once, after all...
>
> However, pg_stat_activity.client_addr is an inet field, not a text
> string, so you'd have to invent a separate field for it I think...

Here is a patch that adds a client_hostname field to pg_stat_activity.
It takes the hostname if it is available either by having log_hostname
set or if the pg_hba.conf processing resolved it. So I think for most
people who would care about this thing, it would "just work".

I'm not so sure about the pgstat.c internals. Do we need the separate
buffer in shared memory, as in this patch, or could we just copy the
name directly into the PgBackendStatus struct? I guess not the latter,
since my compiler complains about copying a string into a volatile
pointer.

Attachment Content-Type Size
pg-stat-activity-client-hostname.patch text/x-patch 19.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-01-15 16:18:59 Re: Add support for logging the current role
Previous Message Tom Lane 2011-01-15 16:14:12 Re: We need to log aborted autovacuums