Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rVCfs-00FTad-WD for pgsql-bugs@arkaria.postgresql.org; Wed, 31 Jan 2024 15:38:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rVCfs-00Ex67-52 for pgsql-bugs@arkaria.postgresql.org; Wed, 31 Jan 2024 15:38:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rVCfr-00Ex5z-TM for pgsql-bugs@lists.postgresql.org; Wed, 31 Jan 2024 15:38:51 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rVCfp-004jex-6J for pgsql-bugs@lists.postgresql.org; Wed, 31 Jan 2024 15:38:51 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 40VFclXp2526290; Wed, 31 Jan 2024 10:38:47 -0500 From: Tom Lane To: gomikioshi@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18318: Different character codes are mixed in the log file in Japanese locale. In-reply-to: <18318-b429273b58c08fa8@postgresql.org> References: <18318-b429273b58c08fa8@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Wed, 31 Jan 2024 09:56:00 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2526288.1706715527.1@sss.pgh.pa.us> Date: Wed, 31 Jan 2024 10:38:47 -0500 Message-ID: <2526289.1706715527@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > Different character codes are mixed in the log file in Japanese locale like > following. This is expected, if you're running an installation that has a mix of different database encodings. Processes will log in whatever encoding is used by the database they're connected to. Processes not connected to any DB will log in the encoding suggested by the locale environment. (At least that's how it works on Unix; less sure about Windows.) There's not much we can do to change this. If we tried to convert all these to a common encoding, what happens if the encoding conversion fails? regards, tom lane