Re: Prepared Statements vs. pgbouncer - Mailing list pgsql-jdbc

From Paul Lindner
Subject Re: Prepared Statements vs. pgbouncer
Date
Msg-id 20071001210922.GQ3140@inuus.com
Whole thread Raw
In response to Re: Prepared Statements vs. pgbouncer  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-jdbc
On Mon, Oct 01, 2007 at 02:44:10PM -0400, Tom Lane wrote:
> Dave Cramer <pg@fastcrypt.com> writes:
> > Josh Berkus wrote:
> >> So where is it going to be easier to fix this ... pgBouncer, or pg-JDBC?
>
> > pgBouncer is broken so I'd fix it.
>
> It's an enormous mistake to imagine that prepared statements are the
> only issue.  What about GUC settings and temp tables, to mention a
> couple other bits of per-session state?

What if you're in a homogenous environment and can control those
variables?

Or for another example, what if you want to create a pool of read-only
replicas and don't care which server gets the request.

What about failover situations?  With stateless clients and the
correct pooling one could seamlessly send requests to a durable
Connection, avoiding a large amount of retry logic in the individual
code.

Perl's adage "Make easy things easy and hard things possible" is
apropos here..

----------------------------------------------------------------------
In fact, here's a crazy idea: static pre-defined session state tied to
roles:

  ALTER ROLE appserver_v1 PREPARE foo() AS ....;
  ALTER ROLE appserver_v1 PREPARE xyz() AS ....;
  ALTER ROLE appserver_v1 SET SESSION stateless=true;

Of course this doesn't help for dynamically prepared statements, which
has been my problem all along...

--
Paul Lindner        ||||| | | | |  |  |  |   |   |
lindner@inuus.com

Attachment

pgsql-jdbc by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: Prepared Statements vs. pgbouncer
Next
From: Oliver Jowett
Date:
Subject: Re: Prepared Statements vs. pgbouncer