Skip site navigation (1) Skip section navigation (2)

Re: [Pgbouncer-general] Prepared Statements vs. pgbouncer

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org, PgBouncer <pgbouncer-general(at)pgfoundry(dot)org>
Subject: Re: [Pgbouncer-general] Prepared Statements vs. pgbouncer
Date: 2007-10-04 16:18:53
Message-ID: e51f66da0710040918xdecee91r38eb7567a4874b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
On 10/4/07, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> > Yes, then you don't need any support from pgbouncer, only
> > a way to drop all prepared plans on session end, which unfortunately
> > is available only in 8.3 - DEALLOCATE ALL / DISCARD ALL.
>
> Oh.  So on 8.2, this is still an issue becuase the plans will persist beyond
> JDBC dropping the connection?

Yes.  JDBC could avoid it by carefully dropping all plans before
closing the connection.

> Also, are you saying that on 8.3 the client
> code will have to manually issue DEALLOCATE ALL on session end?

No, it is pgbouncer's job.  Set server_reset_query to
"DISCARD ALL".  Although that happens to be available only
in 1.1 branch of pgbouncer, which should be released any day now.

In 1.0 it can be done by server_check_query = "..", server_check_delay = 0
but that makes it unusable for it's intended purpose.

-- 
marko

In response to

pgsql-jdbc by date

Next:From: Guy RouillierDate: 2007-10-04 16:38:17
Subject: Re: Connection pooling
Previous:From: Josh BerkusDate: 2007-10-04 15:46:06
Subject: Re: Prepared Statements vs. pgbouncer

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group