On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut <peter.eisentr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
