On Thu, Apr 9, 2015 at 5:46 PM, Andres Freund <andres@anarazel.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@anarazel.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.)