From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Brad Nicholson" <bradn(at)ca(dot)ibm(dot)com> |
Cc: | Thomas Tignor <tptignor(at)yahoo(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, Vijaykumar Jain <vjain(at)opentable(dot)com> |
Subject: | Re: [External] postgres 9.5 DB corruption: invalid byte sequence for encoding "UTF8" |
Date: | 2019-03-26 14:14:32 |
Message-ID: | 18058.1553609672@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Brad Nicholson" <bradn(at)ca(dot)ibm(dot)com> writes:
> Thomas Tignor <tptignor(at)yahoo(dot)com> wrote on 03/25/2019 08:25:49 PM:
>> Thanks for writing. As I mentioned to Vijay, the "source" is a JVM
>> using the postgres v42.0.0 JDBC driver. I do not believe we have any
>> explicit encoding set, and so I expect the client encoding is
>> SQL_ASCII. The DB is most definitely UTF8.
> These statements are contradictory.
> The value of client_encoding from your select on pg_settings is SQL_ASCII.
> The docs clearly state:
> https://www.postgresql.org/docs/9.5/runtime-config-client.html
> "Sets the client-side encoding (character set). The default is to use the
> database encoding. "
> If you don't have client_encoding explicitly, then it is using the database
> encoding.
Umm ... not necessarily. That bit in runtime-config-client.html
correctly states what the *server's* default for client_encoding is,
but an awful lot of client-side code will immediately override that.
psql will try to set it based on its LANG/LC_CTYPE environment,
for example. I don't know what JDBC does; it might be different.
But in any case, yes, it'd be more reliable to check pg_database.encoding
explicitly.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Moreno Andreo | 2019-03-26 14:19:09 | Key encryption and relational integrity |
Previous Message | Adrian Klaver | 2019-03-26 14:08:20 | Re: stale WAL files? |