PQclientEncoding() returns -1, resulting in possible assertion failure in psql

It's possible to get psql to abort() in an assertion failure from
legitimate input. If the server is shutdown, and PQclientEncoding()
returns -1, that value can be passed to a site that expects a valid
encoding.

If the call to PQclientEncoding() from processSQLNamePattern() (plus
probably from other places) gets an encoding of -1, (called when we
"\df+ somefunc" after the server is gone - you may have to do it
twice), that can be passed down to PQmblen(), which will in turn pass
that value to pg_encoding_mblen(), which doesn't expect it. Here is a
backtrace from GDB:

#0 0x00007f0d4a3ba037 in __GI_raise (sig=sig(at)entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f0d4a3bd698 in __GI_abort () at abort.c:90
#2 0x00007f0d4a3b2e03 in __assert_fail_base (fmt=0x7f0d4a50a158
"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion(at)entry=0x7f0d4ac17de8 "((encoding) >= 0 &&
(encoding) < _PG_LAST_ENCODING_)", file=file(at)entry=0x7f0d4ac17de0
"wchar.c", line=line(at)entry=1781,
function=function(at)entry=0x7f0d4ac17e80 <__PRETTY_FUNCTION__.5143>
"pg_encoding_mblen") at assert.c:92
#3 0x00007f0d4a3b2eb2 in __GI___assert_fail (assertion=0x7f0d4ac17de8
"((encoding) >= 0 && (encoding) < _PG_LAST_ENCODING_)",
file=0x7f0d4ac17de0 "wchar.c", line=1781, function=0x7f0d4ac17e80
<__PRETTY_FUNCTION__.5143> "pg_encoding_mblen") at assert.c:101
#4 0x00007f0d4ac13b77 in pg_encoding_mblen (encoding=-1,
mbstr=0xd05d00 "pg_stat_statements") at wchar.c:1781
#5 0x00007f0d4ac01f48 in PQmblen (s=0xd05d00 "pg_stat_statements",
encoding=-1) at fe-misc.c:1143
#6 0x0000000000433ef3 in processSQLNamePattern (conn=0x0,
buf=0x7ffff15dd560, pattern=0xd05d00 "pg_stat_statements",
have_where=0 '\000', force_escape=0 '\000', schemavar=0x44cec1
"n.nspname", namevar=0x44cef9 "p.proname", altnamevar=0x0,
visibilityrule=0x44ced0 "pg_catalog.pg_function_is_visible(p.oid)") at
dumputils.c:1098
#7 0x000000000041e139 in describeFunctions (functypes=0xd036d2 "+",
pattern=0xd05d00 "pg_stat_statements", verbose=1 '\001', showSystem=0
'\000') at describe.c:441
#8 0x0000000000404830 in exec_command (cmd=0xd036d0 "df+",
scan_state=0xcf5550, query_buf=0xcf56c0) at command.c:389
#9 0x0000000000403f7a in HandleSlashCmds (scan_state=0xcf5550,
query_buf=0xcf56c0) at command.c:111
#10 0x000000000040ec66 in MainLoop (source=0x7f0d4a746360
<_IO_2_1_stdin_>) at mainloop.c:301
#11 0x0000000000414b86 in main (argc=1, argv=0x7ffff15ddaf8) at startup.c:329

It's not immediately obvious what the best fix here is - I have some
ideas, but they all seem pretty invasive.

I think it's a bug that processSQLNamePattern() trusts
PQclientEncoding() to return a sane encodingid. Numerous points in
dumputils similarly expect this. The assertion failure isn't spurious,
because the encodingid will subscript an array in pg_encoding_mblen(),
which is undefined here.

--
Peter Geoghegan