Re: parallel workers and client encoding - Mailing list pgsql-hackers

From Tom Lane
Subject Re: parallel workers and client encoding
Date
Msg-id 6067.1465492454@sss.pgh.pa.us
Whole thread Raw
In response to Re: parallel workers and client encoding  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: parallel workers and client encoding  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted