From: | Euler Taveira <euler(at)timbira(dot)com(dot)br> |
---|---|
To: | hillel(dot)eilat(at)attunity(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15230: "Logical decoding" is not sensitive to client encoding setting |
Date: | 2018-06-14 14:28:17 |
Message-ID: | CAHE3wghOn4X2qQk7W+__ZMH8=jGJ81fCQb32xPNhYaELWCdppg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
2018-06-05 5:29 GMT-03:00 PG Bug reporting form <noreply(at)postgresql(dot)org>:
> The plugin used is the common "test_decoding", which is shipped together
> with the kit.
>
What is the test_decoding output mode? By default, it uses textual
mode. Did you set binary mode (foce-binary=1)?
> There is a Japanese database for which encoding is defined as ""EUC_JP".
> Ordinarily - we process the streamed data in UTF8 client encoding - thus
> maintaining a common general "consumer" functions.
> Consequently, prior to issuing PQconnectdbParams(keywords, values, true) - a
> {"client_encoding","UTF8"} couple is introduced.
> To be on the safe side - a couple of PQclientEncoding(pConn) /
> pg_encoding_to_char(iClientEncoding) is issued thereafter,
> for approving that UTF8 was properly set.
>
client_encoding should be set in the replication connection because if
you set it later it won't be passed down to libpqwalreceiver.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2018-06-14 17:50:44 | BUG #15242: JSON functions not recognizing JSON |
Previous Message | Matkar, Prasad L (BHGE) | 2018-06-14 14:16:48 | BUG #15235: Getting failure message "Restore archive operation failed" while restoring database |