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