--- On Tue, 11/1/11, Tatsuo Ishii <[email protected]> wrote: > 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. > >> > 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". > 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
