[Pgpool-general] pool_add_prepared_statement: prepared statement already exists

[Tatsuo Ishii]

>> 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