Re: SSL information view

On Thu, Apr 9, 2015 at 5:46 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2015-04-09 15:56:00 +0200, Magnus Hagander wrote:
> > On Thu, Apr 9, 2015 at 3:20 PM, Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> >
> > > Hi,
> > >
> > > On 2015-04-09 13:31:55 +0200, 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
> > > information about
> > > > + SSL used on this connection.
> > > > + See <xref linkend="pg-stat-ssl-view"> for details.
> > > > + </entry>
> > > > + </row>
> > > > +
> > >
> > > I kinda wonder why this even separate from pg_stat_activity, at least
> > > from the POV of the function gathering the result. This way you have to
> > > join between pg_stat_activity and pg_stat_ssl which will mean that the
> > > two don't necessarily correspond to each other.
> > >
> >
> > To keep from "cluttering" pg_stat_activity for the majority of users who
> > are the ones not actually using SSL.
>
> I'm not sure that's actually a problem. But even if, it seems a bit
> better to return the data for both views from one SRF and just define
> the views differently. That way there's a way to query without the
> danger of matching the wrong rows between pg_stat_activity & stat_ssl
> due to pid reuse.
>

Ah, now I see your point.

Attached is a patch which does this, at least the way I think you meant.
And also fixes a nasty crash bug in the previous one that for some reason
my testing missed (can't set a pointer to null and then expect to use it
later, no... When it's in shared memory, it survives into a new backend.)

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