MIME-Version: 1.0
References: <BN8PR04MB550874EE58EC715656C3D3D2D0B72@BN8PR04MB5508.namprd04.prod.outlook.com>
 <97cfc252-9a26-489e-b458-999ac5589224@aklaver.com> <525679.1744300832@sss.pgh.pa.us>
In-Reply-To: <525679.1744300832@sss.pgh.pa.us>
From: Melanie Plageman <melanieplageman@gmail.com>
Date: Tue, 20 May 2025 11:48:13 -0400
Message-ID: <CAAKRu_ZWKOWCfxsg_nthFusiax9OOiOa8bmCsh06F6QSZ_W5FA@mail.gmail.com>
Subject: Re: Capturing both IP address and hostname in the log
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Adrian Klaver <adrian.klaver@aklaver.com>, 
	"Tefft, Michael J" <Michael.J.Tefft@snapon.com>, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d805280635932db1"
Archived-At: <https://www.postgresql.org/message-id/CAAKRu_ZWKOWCfxsg_nthFusiax9OOiOa8bmCsh06F6QSZ_W5FA%40mail.gmail.com>
Precedence: bulk

--000000000000d805280635932db1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 10, 2025 at 12:00=E2=80=AFPM 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

--000000000000d805280635932db1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote gmail=
_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 10, 202=
5 at 12:00=E2=80=AFPM Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl=
@sss.pgh.pa.us</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
Melanie recently committed a patch (9219093ca) that purports to<br>
generalize our log_connections logging ability:<br>
<br>
=C2=A0 =C2=A0 Convert the boolean log_connections GUC into a list GUC compr=
ised of the<br>
=C2=A0 =C2=A0 connection aspects to log.<br>
<br>
=C2=A0 =C2=A0 This gives users more control over the volume and kind of con=
nection<br>
=C2=A0 =C2=A0 logging.<br>
<br>
=C2=A0 =C2=A0 The current log_connections options are &#39;receipt&#39;, &#=
39;authentication&#39;, and<br>
=C2=A0 =C2=A0 &#39;authorization&#39;. The empty string disables all connec=
tion logging. &#39;all&#39;<br>
=C2=A0 =C2=A0 enables all available connection logging.<br>
<br>
I wonder if it&#39;d be reasonable to remove the separate log_hostname GUC<=
br>
and fold it into this infrastructure, and while doing so make it<br>
possible to log either or both of the client IP address and hostname.<br>
(For that matter, I think there is interest in being able to capture<br>
the server IP address too, cf 3516ea768.=C2=A0 You might wish to log the<br=
>
IP address only once, not in every log line.)</blockquote><div><br></div><d=
iv>Seems reasonable to me. I&#39;d be willing to move such a thing forward =
but would want to see the feature requestors&#39; specific desired behavior=
 (e.g. an option for each of hostname, client ip address, and server addres=
s?). 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.</div><div><br></div><div>Perhaps th=
ere are people who absolutely love log_hostname and don&#39;t want to see i=
t deprecated as a separate GUC?</div><div><br></div><div>I also think foldi=
ng in log_disconnections as a &quot;disconnection&quot; 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.</div><div><br></div><div>- Melanie=
</div></div></div>

--000000000000d805280635932db1--