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.

In cases where it isn't, it's still hard to notice the difference because depending on whether you get a parallel plan or not, the following happens:

not parallel: conversion error happens between server and client, client sees an error message about that

parallel: conversion error happens between worker and leader, worker generates an error message about that, sends it to leader, leader forwards it to client

The client sees the same error message in both cases.

To construct a case where this makes a difference, the leader has to be set up to catch certain errors. Here is an example:

create table test1 (a int, b text);
truncate test1;
insert into test1 values (1, 'a');

create or replace function test1() returns text language plpgsql
as $$
  res text;
  perform from test1 where a = test2();
  return res;
exception when division_by_zero then
  return 'boom';

create or replace function test2() returns int language plpgsql
parallel safe
as $$
  raise division_by_zero using message = 'Motörhead';
  return 1;

set force_parallel_mode to on;

select test1();

With client_encoding = server_encoding, this will return a single row 'boom'. But with, say, database encoding UTF8 and PGCLIENTENCODING=KOI8R, it will error:

ERROR: 22P05: character with byte sequence 0xef 0xbe 0x83 in encoding "UTF8" has no equivalent in encoding "KOI8R"
CONTEXT:  parallel worker

(Note that changing force_parallel_mode does not force replanning in plpgsql, so if you run test1() first before setting force_parallel_mode, then you won't get the error.)

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.

Peter Eisentraut    
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/access/transam/parallel.c 
index 934dba8..d2105ec 100644
--- a/src/backend/access/transam/parallel.c
+++ b/src/backend/access/transam/parallel.c
@@ -775,6 +775,7 @@ HandleParallelMessage(ParallelContext *pcxt, int i, 
StringInfo msg)
                                ErrorData       edata;
                                ErrorContextCallback errctx;
                                ErrorContextCallback *save_error_context_stack;
+                               int save_client_encoding;
                                 * Rethrow the error using the error context 
callbacks that
@@ -787,9 +788,14 @@ HandleParallelMessage(ParallelContext *pcxt, int i, 
StringInfo msg)
                                errctx.previous = pcxt->error_context_stack;
                                error_context_stack = &errctx;
+                               save_client_encoding = pg_get_client_encoding();
+                               SetClientEncoding(GetDatabaseEncoding());
                                /* Parse ErrorResponse or NoticeResponse. */
                                pq_parse_errornotice(msg, &edata);
+                               SetClientEncoding(save_client_encoding);
                                /* Death of a worker isn't enough justification 
for suicide. */
                                edata.elevel = Min(edata.elevel, ERROR);
@@ -989,6 +995,7 @@ ParallelWorkerMain(Datum main_arg)
+       SetClientEncoding(GetDatabaseEncoding());
        /* Crank up a transaction state appropriate to a parallel worker. */
        tstatespace = shm_toc_lookup(toc, PARALLEL_KEY_TRANSACTION_STATE);
Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to