Re: BUG #15230: "Logical decoding" is not sensitive to client encoding setting

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.

[1] https://www.postgresql.org/docs/9.4/static/logicaldecoding-output-plugin.html#LOGICALDECODING-OUTPUT-MODE

--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

In response to

Responses

Browse pgsql-bugs by date

  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