=?UTF-8?Q?Torsten_F=C3=B6rtsch?= <tfoertsch123@xxxxxxxxx> writes: > This hex string decodes to something sensible: > $ perl -le 'print pack "H*", shift' > 246c69626469722f757466385f616e645f69736f383835395f31 > $libdir/utf8_and_iso8859_1 > Maybe it rings a bell. Hah, that's pretty suggestive. So probably, there's an encoding conversion function that's been registered with a messed-up library name, and the failure occurs when trying to connect with a client-side locale that needs to use that encoding conversion. We know the database uses UTF8, so the failure must occur with ISO-8859-1 as the client encoding. It's hard to guess how the function's probin value got messed up though. All those functions should have been created during initdb, and there's no good reason why they should get changed later. I see this in a 9.4 database: regression=# select oid, xmin, proname, probin from pg_proc where probin ~ 'utf8_and_iso8859_1'; oid | xmin | proname | probin -------+------+-------------------+---------------------------- 12392 | 1635 | iso8859_1_to_utf8 | $libdir/utf8_and_iso8859_1 12394 | 1639 | utf8_to_iso8859_1 | $libdir/utf8_and_iso8859_1 (2 rows) although the OIDs and xmin value might vary in other installations. >> And if anyone from the Postgres team listening... in the old tradition of >> whining I would add that the error message referring to a long hex string >> is not helpful! This should be a can't-happen failure ... it's not very clear to me how we could produce a better message for it. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
