From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
Cc: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, david(at)pgmasters(dot)net, Peter Eisentraut <peter(at)eisentraut(dot)org>, Cary Huang <cary(dot)huang(at)highgo(dot)ca>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Logging which local address was connected to in log_line_prefix |
Date: | 2025-03-24 20:59:52 |
Message-ID: | 1154135.1742849992@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> writes:
> In that case, it LGTM.
I looked at 0002 briefly. I don't have any particular objection to
the proposed feature, but I'm quite concerned about the potential
performance implications of doing a new pg_getnameinfo_all() call
for every line of log output. I think that needs to be cached
somehow. It's a little tricky since we may pass through this function
one or more times before the socket info has been filled in, but it
seems do-able.
"Local address" doesn't convey a lot to my mind, and Jim's confusion
about what "[local]" means seems tied to that. Can we think of a
different explanation for the docs? Also, in %h we use "[local]" to
signify a Unix socket, but this patch prints that for both the
Unix-socket case and the case of no client connection at all.
I think "[none]" or some such would be a better idea than "[local]"
for background processes.
The patch pays no attention to the "padding" feature that
all the other switch cases honor.
Also, the coding style is randomly unlike project style in various
details, notably paren placement and the use of "0 == foo" to mean
"!foo".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-03-24 21:10:12 | Re: Logging which local address was connected to in log_line_prefix |
Previous Message | Nathan Bossart | 2025-03-24 20:47:42 | Re: Disabling vacuum truncate for autovacuum |