Re: Addition of authenticated ID to pg_stat_activity

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