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

From Robert Haas
Subject Re: parallel workers and client encoding
Date
Msg-id CA+TgmoZT8OJcEkVL_+=xEFpyLrmR5wWO=hM76EovJgBBR_aZ2A@mail.gmail.com
Whole thread Raw
In response to Re: parallel workers and client encoding  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: parallel workers and client encoding  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Jun 13, 2016 at 10:27 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> Modulo that last point, here is a patch that shows how I think this could
> work, in combination with the patch I posted previously that sets the
> "client encoding" in the parallel worker to the server encoding.
>
> This patch disassembles the NotificationResponse message with a temporary
> client encoding, and then sends it off to the real frontend using the real
> client encoding.
>
> Doing it this way also takes care of a few special cases that
> NotifyMyFrontEnd() handles, such as a client with protocol version 2 that
> doesn't expect a payload in the message.

How does this address the concern raised in the last sentence of
https://www.postgresql.org/message-id/CA+TgmoaAAEXmjVMB4nM=znF_5b9JhUim6q3aFrO4SpT23TiN8g@mail.gmail.com
?  It seems that if an error occurs between the two SetClientEncoding
calls, the change will persist for the rest of the session, resulting
in chaos.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Bug in to_timestamp().
Next
From: Robert Haas
Date:
Subject: Re: Postgres_fdw join pushdown - wrong results with whole-row reference