Re: Logging which local address was connected to in log_line_prefix
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Greg Sabino Mullane <htamfids@gmail.com>, david@pgmasters.net,
Peter Eisentraut <peter@eisentraut.org>,
Cary Huang <cary.huang@highgo.ca>,
"pgsql-hackers@lists.postgresql.org"
<pgsql-hackers@lists.postgresql.org>
Date: 2025-03-24T20:59:52Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add local-address escape "%L" to log_line_prefix.
- 3516ea768c92 18.0 landed
Jim Jones <jim.jones@uni-muenster.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