>> Oops. It seems same unportability regarding dirname(3) as >> main.c is in >> pg_md5.c. Can you please try including patches? >> > > Hmm, still the same message with the patched md5.c > > 2011-01-11 10:57:46 ERROR: pid 5831: pool_init_pool_passwd: couldn't open > /usr/local/etc/pool_passwd. reason: Permission denied >> stop request sent to pgpool. waiting for termination....done.
Hmm. Can you do strace or equivalance against pgpool main process(not child)? >> >> > Also I'm seeing a problem where a namaed >> prepared >> >> statement gets deallocated but pgpool thinks it >> still exists >> >> when my app tries to recreate it. >> >> > >> >> > The output of the log is here: >> >> > >> >> > http://www.privatepaste.com/c3068423a3 >> >> > >> >> > Was thinking it could be something to do with >> this >> >> change? : >> >> > >> >> > http://pgfoundry.org/pipermail/pgpool-committers/2010-October/001507.html >> >> >> >> That change was made by Toshihiro. Toshihiro? >> > >> > I have tried to dig through this myself, however I hit >> a wall when trying to figure out what the differences are >> between a "portal" and a "prepared_statement" in the pgpool >> code. My understanding from a purely postgres point of >> view is that portals are related to cursors, and I'm not >> sure how that applies to the prepared statements here. >> >> Does it? In my understanding "portal" is one of neccessary >> objects to >> process any query, regardless simple or extended. On the >> other hand, >> prepared statements are related to extended query only. In >> the >> extended query protocol, PREPARE phase produces prepared >> statement >> object. In the BIND phase prepared statemet is bind to >> particular >> portal object which should be created beforehand. EXECUTE >> executes >> portal, not prepared statement. Once EXECUTE done, CLOSE >> PORTAL >> discards portal object. But you could leave prepared >> statement as it >> is to re-EXECUTE the query again. >> > > Ah, I understand now, that explanation really helps. When I said "my > understanding" previously, perhaps my point would have been clearer if I'd > said "my understanding as a postgres user, from the postgres docs". Ok. I myself learned this fact in hard way:-) >> Anyway according to Toshihiro, the problem is harder than >> he >> thought. He is working on fixing the problem right now. >> > > Great, thanks. > Glyn _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
