Re: Implementing RESET CONNECTION ... - Mailing list pgsql-patches

From Kris Jurka
Subject Re: Implementing RESET CONNECTION ...
Date
Msg-id Pine.BSO.4.56.0501031603100.3834@leary.csoft.net
Whole thread Raw
In response to Implementing RESET CONNECTION ...  (Hans-Jürgen Schönig <postgres@cybertec.at>)
Responses Re: Implementing RESET CONNECTION ...  (Hans-Jürgen Schönig <postgres@cybertec.at>)
Re: Implementing RESET CONNECTION ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches

On Thu, 30 Dec 2004, [ISO-8859-1] Hans-J�rgen Sch�nig 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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Bgwriter behavior
Next
From: Peter Eisentraut
Date:
Subject: Re: psql session log