[Pgpool-general] pool_add_prepared_statement: prepared statement already exists

[Glyn Astill]

--- On Tue, 11/1/11, Tatsuo Ishii <ishii at sraoss.co.jp> 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