Re: SSL information view - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: SSL information view
Date
Msg-id CABUevEwN+Tg3LihJn5sz7-p59sO-N_EHPRTHVdGXbUAtmaHyAw@mail.gmail.com
Whole thread Raw
In response to Re: SSL information view  (Bernd Helmle <mailings@oopsware.de>)
Responses Re: SSL information view  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Mon, Jul 21, 2014 at 5:24 PM, Bernd Helmle <mailings@oopsware.de> wrote:
>
>
> --On 12. Juli 2014 15:08:01 +0200 Magnus Hagander <magnus@hagander.net>
> wrote:
>
>> Before doing that, however, I'd like to ask for opinions :) The hack
>> currently exposes a separate view that you can join to
>> pg_stat_activity (or pg_stat_replication) on the pid -- this is sort
>> of the same way that pg_stat_replication works in the first place. Do
>> we want something similar to that for a builtin SSL view as well, or
>> do we want to include the fields directly in pg_stat_activity and
>> pg_stat_replication?
>
>
> I've heard more than once the wish to get this information without
> contrib..especially for the SSL version used (client and server likewise).
> So ++1 for this feature.
>
> I'd vote for a special view, that will keep the information into a single
> place and someone can easily join extra information together.

Here's a patch that implements that.

Docs are currently ont included because I'm waiting for the
restructuring of tha section to be done (started by me in a separate
thread) first, but the code is there for review.

Right now it just truncates the dn at NAMEDATALEN - so treating it the
same as we do with hostnames. My guess is this is not a big problem
because in the case of long DNs, most of the time the important stuff
is at the beginning anyway... (And it's not like it's actually used
for authentication, in which case it would of course be a problem).

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Teaching pg_dump to use NOT VALID constraints
Next
From: Steve Singer
Date:
Subject: Re: tracking commit timestamps