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