It was harder to fix than I thought and have no time to look into this. Sorry for this. -- Tatsuo Ishii SRA OSS, Inc. Japan
> Hi Tatsuo. > > I tested the problem against the new version (2.2.5) but the bug is > still present. > > It was what I expected as I didn't see the bug fix in the changelog ;-) > > Thank you, > > Denis > > > Tatsuo Ishii ha scritto: > > Denis, > > > > Thanks for the error report. I was able to reproduce the > > problem. Someone made pgpool-II to ignore some packets from > > backend. That's the reason why you experience the problem. I don't > > know why but apprently it's not good. I am thinking about how to fix > > it but it seems it is harder than I thought. Please give some time... > > -- > > Tatsuo Ishii > > SRA OSS, Inc. Japan > > > > > >> Hi to all. > >> > >> I think there is a very odd behaviour of pgpool when using PQprepare, > >> PQexecPrepare during a transaction. > >> > >> When calling in transaction PQexecPrepare errors are not trapped. > >> Postgres executes the prepared statement terminating with an error but > >> pgpool does not send the error to the client. > >> > >> The problem does not occur when the call to PQexecPrepare is done > >> outside of a transaction block. > >> > >> I attached sample code test.c that reproduces the bug. > >> > >> In order to test it, you must create a sample table in a database named > >> "test" like this: > >> > >> create table test_table( > >> a integer not null > >> ); > >> > >> I'm using pgpool II 2.2.4 in connection pooling mode (no replication or > >> load balance) with postgres 8.2.12. > >> The connections are made to pgpool via socket (dir /var/run, port 11271). > >> > >> Thank you in advance, > >> > >> Doct. Eng. Denis Gasparin > >> --- > >> Edistar SRL _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
