Re: Addition of authenticated ID to pg_stat_activity

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Addition of authenticated ID to pg_stat_activity
Date: 2021-07-21 04:21:17
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, Jul 19, 2021 at 04:56:24PM +0300, Aleksander Alekseev wrote:
> Any reason why we shouldn't simply exclude internal processes from the
> view? Do they have a connection that the VIEW could show?

Yeah, they don't really have any useful information. Still, I kept
that mainly as a matter of consistency with pg_stat_activity, and this
can be useful to find out about internal processes without relying on
an extra check based on pg_stat_activity.backend_type. Perhaps we
could just add a check in system_views.sql based on the NULL-ness of

> Secondly, maybe instead of magic constants like -1, we could use an
> additional text column, e.g. connection_type: "unix"?

I am not really incline to break that more, as told by
pg_stat_get_activity() there are cases where this looks useful:
* Unix sockets always reports NULL for host and -1 for
* port, so it's possible to tell the difference to
* connections we have no permissions to view, or with
* errors.

> Thirdly, not
> sure if client_hostname is really needed, isn't address:port pair
> enough to identify the client?

It seems to me that this is still useful to know about

> Lastly, introducing a new GUC for
> truncating values in a single view, which can only be set at server
> start, doesn't strike me as a great idea. What is the worst-case
> scenario if instead we will always allocate
> `strlen(MyProcPort->authn_id)` and the user will truncate the result
> manually if needed?

The authenticated ID could be a SSL DN longer than the default of
128kB that this patch is proposing. I think that it is a good idea to
provide some way to the user to be able to control that without a

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-07-21 04:58:49 Re: Doc necessity for superuser privileges to execute pg_import_system_collations()
Previous Message David Rowley 2021-07-21 02:52:43 Re: Add proper planner support for ORDER BY / DISTINCT aggregates