From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel workers and client encoding |
Date: | 2016-06-09 17:01:47 |
Message-ID: | CA+TgmoaAAEXmjVMB4nM=znF_5b9JhUim6q3aFrO4SpT23TiN8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-09 17:02:09 | Re: pgsql: Don't generate parallel paths for rels with parallel-restricted |
Previous Message | Robert Haas | 2016-06-09 16:44:47 | Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan) |