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
client_port.
> 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
Port->remote_hostname.
> 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
recompilation.
--
Michael
