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
signature.asc
Description: PGP signature
