Hi Michael, > Just to make the discussion move on, attached is an updated version > doing that.
The code seems OK, but I have mixed feelings about the way that the VIEW currently works. Here is what I get when a single user is connected via a UNIX socket: 43204 (master) =# select * from pg_stat_connection; pid | authenticated_id | client_addr | client_hostname | client_port -------+------------------+-------------+-----------------+------------- 25806 | | | | 25808 | | | | 43204 | | | | -1 25804 | | | | 25803 | | | | 25805 | | | | (6 rows) I bet we could be more user-friendly than this. To begin with, the documentation says: + <para> + The <structname>pg_stat_connection</structname> view will have one row + per server process, showing information related to + the current connection of that process. + </para> [...] + <row> + <entry role="catalog_table_entry"><para role="column_definition"> + <structfield>client_addr</structfield> <type>inet</type> + </para> + <para> + IP address of the client connected to this backend. + If this field is null, it indicates either that the client is + connected via a Unix socket on the server machine or that this is an + internal process such as autovacuum. + </para></entry> + </row> Any reason why we shouldn't simply exclude internal processes from the view? Do they have a connection that the VIEW could show? Secondly, maybe instead of magic constants like -1, we could use an additional text column, e.g. connection_type: "unix"? Thirdly, not sure if client_hostname is really needed, isn't address:port pair enough to identify the client? 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? -- Best regards, Aleksander Alekseev