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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: PQclientEncoding() returns -1, resulting in possible assertion failure in psql
Date: 2013-12-08 18:17:38
Message-ID: 14465.1386526658@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> 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.

A simple fix might be to return SQL_ASCII not -1. I don't think the
-1 behavior is documented or relied on anywhere, is it?

Otherwise, we could check for live connection somewhere much earlier
in the processing of \d and friends. But it might be difficult to
find a single choke point for doing that, rendering the reliability
of the fix somewhat suspect.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dean Rasheed 2013-12-08 18:51:04 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Diway 2013-12-08 17:29:10 bug with json_array_elements on big table ?