Re: System username in pg_stat_activity - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: System username in pg_stat_activity
Date
Msg-id CABUevEz74kTPWKjJSBb8KxQq0518p3eDxgLBQZtJKFGZWojvyw@mail.gmail.com
Whole thread Raw
In response to Re: System username in pg_stat_activity  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: System username in pg_stat_activity
Re: System username in pg_stat_activity
List pgsql-hackers
On Wed, Jan 10, 2024 at 2:56 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi,
>
> On Wed, Jan 10, 2024 at 02:08:03PM +0100, Magnus Hagander wrote:
> > On Wed, Jan 10, 2024 at 1:44 PM Aleksander Alekseev
> > <aleksander@timescale.com> wrote:
> > >
> > > Hi,
> > >
> > > Thanks for the patch.
>
> +1
>
> > > > This overlaps with for example the values in pg_stat_gss, but it will
> > > > include values for authentication methods that don't have their own
> > > > view such as peer/ident. gss/ssl info will of course still be shown,
> > > > it is just in more than one place.
>
> Yeah, I think that's a good idea.
>
> > > It hurts my sense of beauty that usename and authname are of different
> > > types. But if I'm the only one, maybe we can close our eyes on this.
> > > Also I suspect that placing usename and authname in a close proximity
> > > can be somewhat confusing. Perhaps adding authname as the last column
> > > of the view will solve both nitpicks?
> >
> > But it should probably actually be name, given that's the underlying
> > datatype. I kept changing it around and ended up half way in
> > between...
> >
> >
> > > ```
> > > +    /* Information about the authenticated user */
> > > +    char        st_authuser[NAMEDATALEN];
> > > ```
> > >
> > > Well, here it's called "authuser" and it looks like the intention was
> > > to use `name` datatype... I suggest using "authname" everywhere for
> > > consistency.
>
> I think it depends what we want the new field to reflect. If it is the exact
> same thing as the SYSTEM_USER then I think it has to be text (as the SYSTEM_USER
> is made of "auth_method:identity"). Now if we want it to be "only" the identity
> part of it, then the `name` datatype would be fine. I'd vote for the exact same
> thing as the SYSTEM_USER (means auth_method:identity).

I definitely think it should be the same. If it's not exactly the
same, then it should be *two* columns, one with auth method and one
with the name.

And thinking more about it maybe that's cleaner, because that makes it
easier to do things like filter based on auth method?


> > +     <row>
> > +      <entry role="catalog_table_entry"><para role="column_definition">
> > +       <structfield>authname</structfield> <type>name</type>
> > +      </para>
> > +      <para>
> > +       The authentication method and identity (if any) that the user
> > +       used to log in. It contains the same value as
> > +       <xref linkend="system-user" /> returns in the backend.
> > +      </para></entry>
> > +     </row>
>
> I'm fine with auth_method:identity.
>
> > +            S.authname,
>
> What about using system_user as the field name? (because if we keep
> auth_method:identity it's not really the authname anyway).

I was worried system_user or sysuser would both be confusing with the
fact that we have usesysid -- which would reference a *different*
sys...


> Also, what about adding a test in say 003_peer.pl to check that the value matches
> the SYSTEM_USER one?

Yeah, that's a good idea I think. I quickly looked over for tests and
couldn't really find any for pg_stat_activity, btu we can definitely
piggyback them in one or more of the auth tests.

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



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Custom explain options
Next
From: Alexander Lakhin
Date:
Subject: Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed