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 1uyZix-009po2-DQ for pgsql-general@arkaria.postgresql.org; Tue, 16 Sep 2025 17:44:15 +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 1uyZit-001f4K-A2 for pgsql-general@arkaria.postgresql.org; Tue, 16 Sep 2025 17:44:12 +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 1uyZis-001f2P-7i for pgsql-general@lists.postgresql.org; Tue, 16 Sep 2025 17:44:11 +0000 Received: from fhigh-a3-smtp.messagingengine.com ([103.168.172.154]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uyZio-001ASw-0R for pgsql-general@postgresql.org; Tue, 16 Sep 2025 17:44:10 +0000 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id C481C14000DF; Tue, 16 Sep 2025 13:44:05 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Tue, 16 Sep 2025 13:44:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1758044645; x=1758131045; bh=pEf9RzlgdbHOjdIqdA2RFNaoT9Y0s/wkLqSQ2OrrQGo=; b= 2XzMFNYELfhlK4OrU/R3CGfjXX0bVohYDTPa8pgFYKRb9oosQh0URvpMnu+KSkJj PtyvHXHNbL4qm9wweRGdf72AxwNFICbGv6vs27vM1jvtFo/zsA+ybjXPPEZc9PsY kmnqM7PjKiamhmP+ffvW6GOuF1ARhrE1meHjpgAy5aG1zAN1hhKfB5dRNcLcmD23 0+8MnhfQaYjVWmr4t3nryUU/dephXvzlzv6CsjZm29oFw093Obh6I/oSjt6iRm2U nGudh/eiKO4bCqMzpPfakaemwLyw7OVMsIvrWQ7Jd0fCPJno3uvYQqkZCu3BB3dj 4xkDVRxHHERTU4JBa8wSfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1758044645; x=1758131045; bh=p Ef9RzlgdbHOjdIqdA2RFNaoT9Y0s/wkLqSQ2OrrQGo=; b=R1kxGejNBS9d+cyhS Wes1f5Hr+SD3aRS4E3ZiUhhjUPgVbVM/kBKLgk6uxBqthF/YBIGs0oi/doIItMeb +xnd8qvskZBC7ENFJ98YUis08UsaA9HrIpEflxcL5yvBztgoHdaKdjZQB4SYx4gU GQmQbf1yWq/BRlBJRzFdP0geR8J0iCFIzAt7elMP59d4cdnFrkJqeggYjIB8yA4Z QRfwkuxAWLJJ40PkWZZQx7aqoA1SWsByMsdBDKmazBxlWQjFjXdAqjX7xo1Q5opG VVBE5Busx5RF1egYln0R2PN3frf/rCM8xCJlfOEAmHl481rMkEXKt0L7BKSh77nU 3/qaA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeetughrihgrnhcu mfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomheqne cuggftrfgrthhtvghrnhepuddtjeetledtteeggfehhfeutdekjeeiieevvedvieetkeet uddtgedvleffleeknecuffhomhgrihhnpehiudeknhhqrgdrtghomhenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrughrihgrnhdrkhhlrghv vghrsegrkhhlrghvvghrrdgtohhmpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmth hpohhuthdprhgtphhtthhopehjtggrshgrnhhovhesshihshhtvghmghhurghrughsrdgt ohhmrdgvtgdprhgtphhtthhopehpghhsqhhlqdhgvghnvghrrghlsehpohhsthhgrhgvsh hqlhdrohhrgh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 Sep 2025 13:44:04 -0400 (EDT) Message-ID: <235410a2-99dd-47ae-9f26-86b00b7d0623@aklaver.com> Date: Tue, 16 Sep 2025 10:44:04 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: encoding problem while inictial copy in logical replication To: Jaime Casanova , Postgres General References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 9/16/25 04:01, Jaime Casanova wrote: > Hi, > > I have a database with UTF8 encoding. This database seems to be > receiving data in WIN1252 encoding from some client. > > I even see this: > > db=# select * from pg_db_role_setting ; > setdatabase | setrole | setconfig > -------------+----------+------------------------------------------------------------------------------- > 119464 | 0 | > {client_encoding=WIN1252,bytea_output=escape,standard_conforming_strings=off} > (1 rows) > > Some time ago I tried to create a logical replication, for a speed up > I used I created a physical replica and converted it in a logical one > and it works fine. > But the I tried to add a new table to the replica, so I added it to > the publication and when I "ALTER SUBSCRIPTION .... REFRESH > PUBLICATION" got this error. > > 2025-09-16 08:20:24.971 UTC [1535715] LOG: logical replication table > synchronization worker for subscription "sub1", table "new_table" has > started > 2025-09-16 09:20:23.037 UTC [1535715] ERROR: character with byte > sequence 0x8d in encoding "WIN1252" has no equivalent in encoding > "UTF8" > 2025-09-16 09:20:23.037 UTC [1535715] CONTEXT: COPY new_table, line 2489 > 2025-09-16 09:20:23.041 UTC [1463234] LOG: background worker "logical > replication worker" (PID 1535715) exited with exit code 1 > > But if I pg_dump the data directly to the table in the subscription > and avoid the initial copy using copy_data=false, it works fine. > > I tried to "SET client_encoding=UTF8" before the refresh and also > created an user that defaults to client_encoding=UTF8 for using it in > the subscription connection, but I still see the problem during the > initial copy of data. > AFAICS, this doesn't ocurr during normal replication process. > > Any idea? Currently my process is to manually copy the data. Read this?: https://www.i18nqa.com/debug/bug-double-conversion.html https://www.i18nqa.com/debug/utf8-debug.html Bottom line 0x8d is unassigned in WIN1252 and there is no UTF8 equivalent for it and four other code points. The solution would seem to be determining what is using this code point and stopping it's use if possible. > > -- > Jaime Casanova > SYSTEMGUARDS > Director de servicios profesionales > > -- Adrian Klaver adrian.klaver@aklaver.com