[Pgpool-general] pool_add_prepared_statement: prepared statement already exists

[Tatsuo Ishii]

> --- On Tue, 11/1/11, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> 
>> > The previous error with the
>> pool_passwd appears to have gone on startup, but it still
>> appears when the server is stopped.
>> 
>> Can you please explain more detail?
>> 
> 
> When I stop pgpool-II I get the following message:
> 
> 2011-01-11 09:44:18 ERROR: pid 13462: pool_init_pool_passwd: couldn't open /usr/local/etc/pool_passwd. reason: Permission denied
> stop request sent to pgpool. waiting for termination....done.
> 
> This doesn't seem to cause a problem, so is it expected behaviour?

Oops. It seems same unportability regarding dirname(3) as main.c is in
pg_md5.c. Can you please try including patches?

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

Anyway according to Toshihiro, the problem is harder than he
thought. He is working on fixing the problem right now.

> Thanks for your help guys.
> Glyn
> 
> 
>       
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pg_md5.c.patch
Type: text/x-patch
Size: 1038 bytes
Desc: not available
URL: <http://pgfoundry.org/pipermail/pgpool-general/attachments/20110111/2bc939b7/attachment.bin>