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

[Tatsuo Ishii]

> One thing I did think about yesterday....
> 
> If the node these statements are being sent to fails, then these
> statements are going to blow up when they try to send to another node.

In this case pgpool restarts all children processes. That means all of
current sessions are restarting and you do not need worry about
already sent statements anyway.

> Perhaps instead of just trusting the pool_where_to_send from the
> Parse, we should be sending Parse / Bind / Describe to -all- nodes,
> and directing the Execute to only one of them?
>
> That way, if a transaction starts and pool_where_to_send determines
> the Execute needs to go to the primary, or if a node fails, any place
> the Execute would be directed to would be a valid target. Right?
> 
> Would doing Parse / Bind / Describe on all backends be a major
> performance hit? And would that negate any benefit of load-balancing
> SELECT?

For non SELECTs you cannot not do those on standbys because PostgreSQL
does not allow it. For SELECTs, yes you can do. Actually before we did
it. If my memory serves, that had one bad side effect: VACUUM is
blocked by unnecessarily parsed statements on slaves. However in
streaming replication mode, VACUUM does not run slaves of course. So
we can do Parse / Bind / Describe on all backends. There may be a pit
fall with this thought though.

> I just worry about the robustness of targeting single servers.
> 
> -Bryan
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general