Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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:

Re: [HACKERS] parallel workers and client encoding

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,

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

> 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 >

Re: [HACKERS] parallel workers and client encoding

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 >>

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

Re: [HACKERS] parallel workers and client encoding

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

[HACKERS] parallel workers and client encoding

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