Re: Setting log_connection in connection string doesn't work - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Setting log_connection in connection string doesn't work
Date
Msg-id YXixkyUXQH9/BSKO@paquier.xyz
Whole thread Raw
In response to Re: Setting log_connection in connection string doesn't work  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Setting log_connection in connection string doesn't work  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Wed, Oct 27, 2021 at 10:24:05AM +0900, Kyotaro Horiguchi wrote:
> I don't know. The fact is that it's a superuser-backend variable that
> is silently ignored (but acutally seems to be set in the session).
> Setting log_disconnection the same way works (of course the impliction
> of this is far less significant that the log_connection case).

fe550b2 is the commit that has changed both those parameters to be
PGC_SU_BACKEND, with the commit log mentioning the case you are
describing.  That would be the area of this thread:
https://www.postgresql.org/message-id/20408.1404329822@sss.pgh.pa.us

As Tom and this thread are saying, there may be a use-case for
making log_connections more effective at startup so as superusers
could hide their logs at will.  However, honestly, I am not sure that
this is worth spending time improving this as the use-case looks
rather thin to me.  Perhaps you are right and we could just mark both
of those GUCs as PGC_SIGHUP, making the whole easier to understand and
more consistent, though.  If we do that, the patch is wrong, as the
docs would also need a refresh.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber
Next
From: Amit Kapila
Date:
Subject: Re: pgsql: Remove unused wait events.