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.

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.

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

Reply via email to