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

Re: Implementing RESET CONNECTION ...

From: Kris Jurka <books(at)ejurka(dot)com>
To: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
Cc: pgsql-patche(at)postgresql(dot)org, pgman(at)candle(dot)pha(dot)pa(dot)us,eg(at)cybertec(dot)at, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>,pgsql-patches(at)postgresql(dot)org
Subject: Re: Implementing RESET CONNECTION ...
Date: 2005-01-03 21:17:40
Message-ID: Pine.BSO.4.56.0501031603100.3834@leary.csoft.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

On Thu, 30 Dec 2004, [ISO-8859-1] Hans-Jrgen Schnig wrote:

> We have implemented a patch which can be used by connection pools for
> instance. RESECT CONNECTION cleans up a backend so that it can be
> reused. Temp tables, LISTEN / NOTIFY stuff, WITH HOLD cursors, open
> transactions, prepared statements and GUCs are cleaned up. I hope we
> have not missed important per-backend information.
> 

From the JDBC driver's perspective this doesn't meet the needs I'd like to
see in a connection reset.  In the initial connection setup a number of
GUC variables are tweaked to what the JDBC driver desires (DateStyle,
client_encoding).  When resetting we'd want to reset to this point, not
the default values.  Perhaps some kind of MARK command, kind of like a
savepoint to rollback to would better specify this.

Also I don't like the idea of cleaning up prepared statements.  While it
doesn't do so now, the JDBC driver would like to do statement pooling at
some point.  This means the same underlying server prepared statement can
be reused transparently from multiple callers.  In a connection pool where
a connection is grabbed and returned for virtually each sql execution this
is key to getting the performance boost from prepared statements.  We
don't want to have to reprepare on each connection and we don't want them
to disappear from underneath us, because the prepared statements are
generated transparently by the JDBC driver, not directly by a user
statement.

Kris Jurka

In response to

Responses

pgsql-hackers by date

Next:From: ntinosDate: 2005-01-03 21:18:19
Subject: Re: Can't find relation oid
Previous:From: Martijn van OosterhoutDate: 2005-01-03 21:05:47
Subject: Re: Can't find relation oid

pgsql-patches by date

Next:From: Peter EisentrautDate: 2005-01-03 21:47:52
Subject: Re: psql session log
Previous:From: Heikki LinnakangasDate: 2005-01-03 20:52:00
Subject: ipcrm or ipcclean hint

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