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
