| From: | Jacob Champion <pchampion(at)vmware(dot)com> |
|---|---|
| To: | "peter(dot)eisentraut(at)enterprisedb(dot)com" <peter(dot)eisentraut(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Log details for client certificate failures |
| Date: | 2022-05-03 23:05:30 |
| Message-ID: | a922e857c4e4a073f219bc5005b862eb22255c20.camel@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2022-05-03 at 21:06 +0200, Peter Eisentraut wrote:
> The information in pg_stat_ssl is limited to NAMEDATALEN (see struct
> PgBackendSSLStatus).
>
> It might make sense to align what your patch prints to identify
> certificates with what is shown in that view.
Sure, a max length should be easy enough to do. Is there a reason to
limit to NAMEDATALEN specifically? I was under the impression that we
would rather not have had that limitation in the stats framework, if we
could have avoided it. (In particular I think NAMEDATALEN will cut off
the longest possible Common Name by just five bytes.)
Thanks,
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2022-05-03 23:44:13 | Re: Perform streaming logical transactions by background workers and parallel apply |
| Previous Message | David Steele | 2022-05-03 21:47:21 | Re: pg_walcleaner - new tool to detect, archive and delete the unneeded wal files (was Re: pg_archivecleanup - add the ability to detect, archive and delete the unneeded wal files on the primary) |