On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut >> <peter.eisentr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers