Re: parallel workers and client encoding
От | Tom Lane |
---|---|
Тема | Re: parallel workers and client encoding |
Дата | |
Msg-id | 7230.1465494454@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: parallel workers and client encoding (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: parallel workers and client encoding
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. > So, I don't think this is true. First, to be clear, there's no > encoding conversion going on when tuples are sent from worker to > leader, so that case has no problem of this type at all. This is > limited to non-tuple protocol messages: errors, notices, and possibly > notifies. Okay ... > Second, if you can't convert an error or notice message (or possibly a > notify message) from the server encoding to the client coding, you are > definitely going to fail, with or without parallel query, because that > conversion has to be done at some stage anyway. Only if the message gets sent to the client, which it might never be; for example because the query is inside a plpgsql exception block that traps the error. You do have a bug here; please don't argue you don't. regards, tom lane
В списке pgsql-hackers по дате отправления: