[Pgpool-general] Trouble with the JDBC drivers...

[Tatsuo Ishii]

>> It seems the code tries to do what you said.  There are many places
>> calling pool_create_sent_message().  In my understanding the function
>> tries to remember where Parse/Bind messges have been sent. For
>> example, Parse() calles like this:
>>
>> 		msg = pool_create_sent_message('P', len, contents, 0, name,
>> 		query_context);
>>
>> Afterward Bind() tries to extract the data:
>>
>> 	parse_msg = pool_get_sent_message('Q', pstmt_name);
>>
>> Aafter several lines Bind() calls this.
>>
>> 	pool_where_to_send(query_context, query_context->original_query,
>> 					   query_context->parse_tree);
>>
>> I think problem is here.
>>
>> pool_where_to_send() decides to choose node(s) bind messages should be
>> sent to. The function has been called when Parse() gets called to
>> determine the destination node as well. pool_where_to_send() makes the
>> decision by using current condition, inckuding transaction state. And
>> Bind() does the same job by calling pool_where_to_send(). But what if
>> the condition has been changed between Parse() and Bind()? It is
>> possible that desitination node could be different and bind message
>> might be sent to a node where parse never gets executed. I think at
>> least part of problems you are having comes from this. Bind() should
>> not call pool_where_to_send() instead inherits the desitination node
>> from Parse() in my opinion.
> 
> I've also been able to verify that Execute() will send to destinations
> different from Bind(), and that's when I get invalid portal name
> errors from the backend. I think this is happening at both levels,
> Bind & Execute.

Hmm. Question is why you get invalid portal name errors in the first
place.

> I agree that the easiest fix here is to simply not invoke
> pool_where_to_send for Bind or Execute, but to inherit where they were
> Parse()ed at.
> 
> I had been playing with the idea of re-parsing / re-binding statements
> if there was a mismatch, but I'm not convinced it's the right thing to
> do, or that the overhead would be worth it.

Yeah, without dealing with the problem above, I'm afraid re-parsing /
re-binding approach brings more troubles...

> I'll try out the other method you've described, and see what happens.
> 
> Regards,
> -Bryan