On Tue, Aug 04, 2015 at 11:32:11PM -0400, Noah Misch wrote:
> On Wed, Jun 10, 2015 at 02:32:35PM +0000, Dmitri.Bourlatchkov@software.dell.com wrote:
> > 4. Run postgresql.exe (no args)
> > 5. Observe the following error message:
> >
> > ----
> > FATAL: XX000: cannot perform encoding conversion outside a transaction
> > LOCATION: pg_do_encoding_conversion, src\backend\utils\mb\mbutils.c:360
> > ----
> Commit 49c817e is the proximate cause. On my Windows Server 2008 system,
> Korean is the only locale affected. It's affected because pg_enc2name_tbl
> lacks a UHC <-> CP949 mapping. I'll double check, but adding that mapping
> should fix this particular test case.
>
> That leaves other ways of reaching this error. I think e.g. an LC_CTYPE=C,
> ENCODING=LATIN9 database will still take this path.
LATIN9 does not, but LATIN8 does. Plain 'make check' fails early in Korean
locales, and 'make check EXTRA_REGRESS_OPTS="--encoding=LATIN8 --no-locale"'
fails in any OS locale.
> Any EmitErrorReport() can
> run pgwin32_message_to_UTF16(), and those have plenty of ways to run outside a
> transaction. I am inclined to restore the 9.3 and earlier semantics by having
> pgwin32_message_to_UTF16() proceed, when outside a transaction, as though the
> string is already UTF8.
I am attaching the two patches I plan to use. Either one by itself fixes the
symptom you observed.
> A robust fix would be to cache enough information
> about the message encoding to convert outside a transaction, exactly the way
> we protect database<->client encoding conversions. That feels more like a
> master-only change, though it's a borderline case.
I propose to add this to https://wiki.postgresql.org/wiki/Todo:
* Multi-Language Support
** Windows: Cache MessageEncoding conversion for use outside transactions
Thanks,
nm
