Re: parallel workers and client encoding

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: parallel workers and client encoding
Date: 2016-06-09 17:14:14
Message-ID: 6067.1465492454@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-06-09 17:26:41 Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
Previous Message Robert Haas 2016-06-09 17:07:59 Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116