>> 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
_______________________________________________
Pgpool-general mailing list
Pgpool-general@pgfoundry.org
http://pgfoundry.org/mailman/listinfo/pgpool-general
