Addition of authenticated ID to pg_stat_activity - Mailing list pgsql-hackers

From Michael Paquier
Subject Addition of authenticated ID to pg_stat_activity
Date
Msg-id YIYmqIERKlgqmkZ6@paquier.xyz
Whole thread Raw
Responses Re: Addition of authenticated ID to pg_stat_activity
Re: Addition of authenticated ID to pg_stat_activity
List pgsql-hackers
Hi all,

9afffcb has added the concept of authenticated identity to the
information provided in log_connections for audit purposes, with this
data stored in each backend's port.  One extra thing that can be
really useful for monitoring is the capability to track this
information directly in pg_stat_activity.

Please find attached a patch to do that, with the following choices
made:
- Like query strings, authenticated IDs could be rather long, so we
need a GUC to control the maximum size allocated for these in shared
memory.  The attached uses 128 bytes by default, that should be enough
in most cases even for DNs, LDAP or krb5.
- Multi-byte strings need to be truncated appropriately.  As a matter
of consistency with the query string code, I have made things so as
the truncation is done each time a string is requested, with
PgBackendStatus storing the raw information truncated depending on the
maximum size allowed at the GUC level.
- Some tests are added within the SSL and LDAP code paths.  We could
add more of that within the authentication and kerberos tests but that
did not strike me as mandatory either as the backend logs are checked
everywhere already.
- The new field has been added at the end of pg_stat_end_activity()
mainly as a matter of readability.  I'd rather move that just after
the application_name, now only pg_stat_activity does that.

I am adding that to the next CF.

Thanks,
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Replication slot stats misgivings
Next
From: Bharath Rupireddy
Date:
Subject: Re: PageGetItemIdCareful - should we MAXALIGN sizeof(BTPageOpaqueData)?