> Some notices: First we issue a prepared SELECT NEXTVAL in a transaction. > This is only send to the master. Later we try to deallocate the prepared > statement. This works on the master, but fails on the slaves. Seems to > be a logic flaw. > > I wrote a little patch to fix this:
Thanks for the patch. However I found that this bug was fixed before. > Do not force replication of DEALLOCATE if operated in master/slave > mode. Now that pgpool do not execute PARSE in all nodes, this was > pointless and caused problem (kind mismatch when executing DEALLOCATE). > > http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgpool/pgpool-II/pool_proto_modules.c.diff?r1=1.28&r2=1.29&f=u I have committed following patch to fix enbug in CVS branch 2.3-STABLE. http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgpool/pgpool-II/pool_proto_modules.c.diff?r1=1.37&r2=1.37.2.1 -- Toshihiro Kitagawa SRA OSS, Inc. Japan _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
