On Wed, Jun 29, 2016 at 10:52 PM, Peter Eisentraut
wrote:
> I'm happy with this patch.
Great. I have committed it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
I'm happy with this patch.
On 6/29/16 12:41 PM, Robert Haas wrote:
On Tue, Jun 28, 2016 at 10:10 PM, Peter Eisentraut
wrote:
On 6/27/16 5:37 PM, Robert Haas wrote:
Please find attached an a patch for a proposed alternative approach.
This does the following:
1. When the client_encoding GUC i
On Tue, Jun 28, 2016 at 10:10 PM, Peter Eisentraut
wrote:
> On 6/27/16 5:37 PM, Robert Haas wrote:
>> Please find attached an a patch for a proposed alternative approach.
>> This does the following:
>>
>> 1. When the client_encoding GUC is changed in the worker,
>> SetClientEncoding() is not calle
On 6/27/16 5:37 PM, Robert Haas wrote:
Please find attached an a patch for a proposed alternative approach.
This does the following:
1. When the client_encoding GUC is changed in the worker,
SetClientEncoding() is not called.
I think this could be a problem, because then the client encoding in
On Mon, Jun 27, 2016 at 12:53 PM, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 10:27 PM, Peter Eisentraut
> 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 para
On Mon, Jun 13, 2016 at 10:27 PM, Peter Eisentraut
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 disassembl
On Mon, Jun 13, 2016 at 9:39 AM, Robert Haas wrote:
> There is no realistic way that I am going to have this fixed before
> beta2. There are currently 10 open items listed on the open items
> page, of which 8 relate to my commits and 5 to parallel query in
> particular. I am not going to get 8 i
On 6/9/16 7:16 PM, Tatsuo Ishii wrote:
Something like SetClientEncoding(GetDatabaseEncoding()) is a Little
bit ugly. It would be nice if we could have a switch to turn off the
automatic encoding conversion in the future, but for 9.6, I feel I'm
fine with your proposed patch.
One way to make thi
On 6/10/16 2:08 PM, Peter Eisentraut wrote:
On 6/6/16 9:45 PM, Peter Eisentraut wrote:
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.
Tracing the code, NotificationResponse mes
On Sun, Jun 12, 2016 at 3:05 AM, Noah Misch wrote:
> On Thu, Jun 09, 2016 at 12:04:59PM -0400, Peter Eisentraut wrote:
>> On 6/6/16 9:45 PM, Peter Eisentraut wrote:
>> >There appears to be a problem with how client encoding is handled in the
>> >communication from parallel workers.
>>
>> I have ad
On Thu, Jun 09, 2016 at 12:04:59PM -0400, Peter Eisentraut wrote:
> On 6/6/16 9:45 PM, Peter Eisentraut wrote:
> >There appears to be a problem with how client encoding is handled in the
> >communication from parallel workers.
>
> I have added this to the open items for now.
[Action required with
On 6/6/16 9:45 PM, Peter Eisentraut wrote:
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.
Tracing the code, NotificationResponse messages are converted to the
client encoding d
> There appears to be a problem with how client encoding is handled in
> the communication from parallel workers.
Ouch.
> 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
On Thu, Jun 9, 2016 at 1:47 PM, Tom Lane wrote:
>> 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
Robert Haas writes:
> On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane 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-p
On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
>> 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
Robert Haas writes:
> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
> 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.
On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
wrote:
> 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
On 6/6/16 9:45 PM, Peter Eisentraut wrote:
There appears to be a problem with how client encoding is handled in the
communication from parallel workers.
I have added this to the open items for now.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
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 a
20 matches
Mail list logo
