From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SSL information view |
Date: | 2015-01-06 11:09:05 |
Message-ID: | CABUevEzPZ9fb6x-38HBXFrFtkKgo7d91WCEWip0FTxOZzWOUQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 5, 2015 at 9:56 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 11/19/14 7:36 AM, Magnus Hagander wrote:
> > + <row>
> > +
> <entry><structname>pg_stat_ssl</><indexterm><primary>pg_stat_ssl</primary></indexterm></entry>
> > + <entry>One row per connection (regular and replication), showing
> statistics about
> > + SSL used on this connection.
> > + See <xref linkend="pg-stat-ssl-view"> for details.
> > + </entry>
> > + </row>
> > +
>
> It doesn't really show "statistics". It shows information or data.
>
Good point.
We should make contrib/sslinfo a wrapper around this view as much as
> possible.
>
Agreed - but let's do that as a separate patch.
Is it useful to include rows for sessions not using SSL?
>
I think so, mainly because it makes things "more obvious" that you are
querying it the right way. Sure you could do a LEFT JOIN from
pg_stat_activity and a CASE to get the same results, but that makes it a
lot less in-your-face.
Should we perpetuate the "ssl"-naming? Is there a more general term?
>
tls? :)
We call it ssl everywhere else, I think being consistent is important.
Will this work for non-OpenSSL implementations?
>
Yes, it uses (and declares new) the new internal APIs that Heikki created.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2015-01-06 12:12:09 | Re: tracking commit timestamps |
Previous Message | Abhijit Menon-Sen | 2015-01-06 10:43:53 | Re: What exactly is our CRC algorithm? |