Re: Setting log_connection in connection string doesn't work

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Setting log_connection in connection string doesn't work
Date: 2021-10-27 01:55:31
Message-ID: YXixkyUXQH9/BSKO@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-10-27 02:00:20 Re: pgsql: Remove unused wait events.
Previous Message Japin Li 2021-10-27 01:40:09 Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber