On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.com> wrote:
>>> ... So this whole thing
>>> actually happens to work as long as round tripping is possible between the
>>> involved encodings.
>
>> Hmm. I didn't realize that we had encodings where round-tripping
>> wasn't possible. I figured that if you could convert from A to B, you
>> would also be able to convert from B to A.
>
> Uh, that's not the point: the real problem is when B is simply smaller
> than A. For example, server encoding utf8, client encoding latin1.
> The current code results in failures if any non-latin1 data has to be
> transmitted from worker to leader, even though the query might not have
> ever sent that data to the client, and therefore would work fine in
> non-parallel mode.
So, I don't think this is true. First, to be clear, there's no
encoding conversion going on when tuples are sent from worker to
leader, so that case has no problem of this type at all. This is
limited to non-tuple protocol messages: errors, notices, and possibly
notifies.
Second, if you can't convert an error or notice message (or possibly a
notify message) from the server encoding to the client coding, you are
definitely going to fail, with or without parallel query, because that
conversion has to be done at some stage anyway. The difference is
that without parallel query, we convert server->client and that's it,
whereas with parallel query we convert server->client->server->client
if the error occurs in the worker, and so the conversion in the
reverse direction (client back to server) can introduce a failure that
couldn't occur otherwise.
That's a pretty obscure corner case, but of course it should still be fixed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company