Re: parallel workers and client encoding

On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> There appears to be a problem with how client encoding is handled in the
> communication from parallel workers.  In a parallel worker, the client
> encoding setting is inherited from its creating process as part of the GUC
> setup.  So any plain-text stuff the parallel worker sends to its leader is
> actually converted to the client encoding.  Since most data is sent in
> binary format, the plain-text provision applies mainly to notice and error
> messages.  At the other end, error messages are parsed using
> pq_parse_errornotice(), which internally uses routines that were meant for
> communication from the client, and therefore will convert everything back
> from the client encoding to the server encoding.  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.  I see that this isn't
necessarily true in theory, but I had assumed (incorrectly, it seems)
that it was true in practice.  It seems very odd to me.

> Attached is a patch to illustrates how this could be fixed.  There might be
> similar issues elsewhere.  The notification propagation in particular could
> be affected.

Making the parallel worker always use the database encoding seems like
a good approach to me, but won't the changes you made to
HandleParallelMessage() leave the expect client encoding in the wrong
state if pq_parse_errornotice throws an error?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company