Re: SSL information view
От | Magnus Hagander |
---|---|
Тема | Re: SSL information view |
Дата | |
Msg-id | CABUevEyff7hP=3sqjqoY-6-CpojRTuV6c9VqDnZHz8nN6_Xk2g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SSL information view (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: SSL information view
|
Список | pgsql-hackers |
On Thu, Apr 9, 2015 at 5:46 PM, Andres Freund <andres@anarazel.de> wrote:
I'm not sure that's actually a problem. But even if, it seems a bitOn 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.
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.)
Вложения
В списке pgsql-hackers по дате отправления: