Re: Capturing both IP address and hostname in the log
От | Melanie Plageman |
---|---|
Тема | Re: Capturing both IP address and hostname in the log |
Дата | |
Msg-id | CAAKRu_ZWKOWCfxsg_nthFusiax9OOiOa8bmCsh06F6QSZ_W5FA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Capturing both IP address and hostname in the log (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Apr 10, 2025 at 12:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Melanie recently committed a patch (9219093ca) that purports to
generalize our log_connections logging ability:
Convert the boolean log_connections GUC into a list GUC comprised of the
connection aspects to log.
This gives users more control over the volume and kind of connection
logging.
The current log_connections options are 'receipt', 'authentication', and
'authorization'. The empty string disables all connection logging. 'all'
enables all available connection logging.
I wonder if it'd be reasonable to remove the separate log_hostname GUC
and fold it into this infrastructure, and while doing so make it
possible to log either or both of the client IP address and hostname.
(For that matter, I think there is interest in being able to capture
the server IP address too, cf 3516ea768. You might wish to log the
IP address only once, not in every log line.)
Seems reasonable to me. I'd be willing to move such a thing forward but would want to see the feature requestors' specific desired behavior (e.g. an option for each of hostname, client ip address, and server address?). Also, if they write a WIP patch at least to config.sgml, it would also help me gauge how serious of a request it is or, rather, how satisfactory a solution a log_connections option is.
Perhaps there are people who absolutely love log_hostname and don't want to see it deprecated as a separate GUC?
I also think folding in log_disconnections as a "disconnection" option makes sense. I do have some anxiety that a very long list of options will anger users -- but I suppose that ship mostly sailed.
- Melanie
В списке pgsql-hackers по дате отправления: